Hallo liebes Forum,
ich habe ein Programm geschrieben welche ein analoges Spannungssignal einliest, es verarbeitet und einen 1Bit digitalen Wert wieder ausgibt. Das Einlesen und das Ausgeben der Werte habe ich momentan mit dem DAQ assistent realisiert und jeweils das ein und auslesen in zwei while schleifen gepackt wo der DAQ assistent lediglich die Daten in eine lokale Variable schreibt bzw. aus einer lokalen Variable liest. Die beiden DAQ assistent sind auf (1 Sample (on demand)) eingestellt. Die Schleifen sollten also so schnell wie moeglich durchlaufen und immer einen neuen Wert in die lokalen Variablen schreiben bzw. lesen
Da mein Programm sehr schnell laufen muss habe ich die Zeiten fuer einen Schleifendurchlauf gemessen. Dieser liegt jeweis bei ca. 2ms, was noch wesentlich zu langsam ist.
Ich habe die Karte NI PCIe-6321. Diese sollte im Stande sein mit 250 kS/s pro 16 Kanaele ein analoges Signal zu erfassen und mit 1 MHz ein digitales Signal auszugeben. Die Hardware muesste also schnell genug sein.
Ich habe auch schon versucht herauszufinden wie der DAQ asisstent funktioniert um ihn zu vereinfachen, allerdings hat das nicht viel gebraucht.
Wie kann ich die Daten in "echtzeit" in mein Labviewprogramm in eine lokale Variable schreiben?
Danke schonmal.
Tobs
Hallo Tobs,
in erster Instanz stellt sich die Frage was du genau machen möchtest.
Wenn du deine Verarbeitung auf einzelne analoge Datenpunkte durchführst und dann einen Digitalwert ausgibst wirst du nicht sehr viel schneller werden können. Limitierend wirkt hierbei dein PC. Die Datenerfassungsraten und -ausgaberaten erreichst du nur mit gepufferten Operationen direkt auf der Karte ohne Einzelverarbeitung in deiner Software.
Also wenn du mir sagst was du eigentlich erreichen möchtest kann dir sicher geholfen werden.
Hallo Holy,
danke schonmal für deine Antwort.
Hier das Problem:
Ich habe einen Servomotor, den ich mit einem Rechtecksignal zwischen -10 bis 10V ansteuere. Abhaengig von der Spannung ergibt sich dann ein Winkel. Auf grund der Traegheit vollfuehrt der Motor anstatt des aufgetragenen Rechtecksignals eine sinusaehnliche Schwingung welches ich mit einem Winkelsensor auslese der mir eine Signal zwischen -5 bis 5 V ausgibt.
Abhaenig von der Position des Motors moechte ich nun einen Laser mit einem digitales Signal aus und anschalten. Der Laser soll immer wieder an der gleichen Winkelposition des Morors an bzw. aus gehen
z.B.: 0V-0,1V=1; 0,1V-0,2V=0; 0,2V-0,3V=1 usw. Der Laser soll bei jeder schwinung des Motors ca. 100 mal an und aus gehen.
Die Frequenz mit der ich den Motor betreibe variiert zwischen 100 bis 200Hz.
Die Pulsweite des Digitalen Singnals die Frequenz und die Phase soll sich in Abhaengigkeit zum eingangssignal einstellen lassen. Eine schematische Darstellung ist im Anhang.
Im Anhang habe ich auch in eim Flussdiagramm dargestellt wie mein Labviewprogramm zur Zeit aufgebaut ist (bitte die grauen Kästchen wegdenken.... die sind ein fehler). Zur Zeit wird mein Programm nur vom einlesen der Position (analoges Eingangssignal) und schreiben des Laser status (digitaler Ausgag) ausgebremst.
Zitat: "Wenn du deine Verarbeitung auf einzelne analoge Datenpunkte durchführst und dann einen Digitalwert ausgibst wirst du nicht sehr viel schneller werden können."
Ich bin mir nicht ganz sicher, aber ich hoffe ich habe nicht dieses Problem.
Ich hoffe ich konnte meine Aufgabe anschaulich beschreiben... an sonsten immer raus mit den Fragen!
Danke!
Viele Grüße. Tobs
(08.04.2011 20:34 )Tobs schrieb: [ -> ]ich habe ein Programm geschrieben welche ein analoges Spannungssignal einliest, es verarbeitet und einen 1Bit digitalen Wert wieder ausgibt.
Das ist eine Regelung.
Das wird in ganz normalem LabVIEW nicht funktionieren. Nicht weil du lokale Variablen verwendest, sondern weil ein PC-System für sowas nicht geeignet ist. Hier stören dich so Sachen wie Betriebssystem (Multitasking, Prozesslevel etc) viel, viel mehr. Regeln kann man nur mit den geeigneten Mittels. Für dich geeignet wäre möglicherweise ein Echtzeitsystem oder noch besser eine Hardware-Lösung.
(11.04.2011 00:09 )Tobs schrieb: [ -> ]Hier das Problem:
Hast du mal ausgerechnet, welche Genauigkeit in µs du haben willst?
Eine Möglichkeit sehe ich schon:
Wenn die Motordrehzahl feststeht (und konstant ist), kannst du parallel zur Ausgabe der Motor-PWM auch das Lasersignal ausgeben. Du musst ja nicht unbedingt eine Regelung für den Laser nehmen. Du kannst ja auch durch eine mathematische Berechnung festlegen, zu welchen Zeiten der Laser eingeschaltet werden muss. Da du das Tiefpassverhalten des Motor kennst, kannst du vorhersagen, zu welcher Zeit welcher Winkel anliegt. Dann kannst du einen digitalen Datenstream ausgeben lassen, was durch eine entsprechende Karte auch in einem PC möglich ist.
Diese Berechnung ist zwar nicht trivial, aber besser als mit Software-Regelung.
Eine richtige Regelung ist natürlich vorzuziehen - geht aber wohl nur mit entsprechender Hardware.
Hallo,
danke nochmal fuer deine Antwort.
Wenn ich das jetzt richtig verstanden habe, dann wird das mit der Regelung mit meinem Programm wohl nicht klappen.
Eine genaue Angabe auf wie viel µs genau mein Laser geschaltet werden muss kann ich nicht geben. Das ganze ist in einem Lasermikroskop eingebaut. Desto genauer ich den Laser steuern kann, desto besser wird meine Bildqualitaet. Es ist also alles etwas subjektiv.
Eine Hardwareloesung moechte ich erstmal noch nicht in betracht ziehen, solange ich nicht meine resorcen bis jetzt ausgeschoepft habe.
Ueber deinen Loeungsvorschlag mit der zeitabhaenigen Regelung des Lasers habe ich auch schon einmal nachgedacht. Ich weiss allerdings nicht so genau wie ich die beiden Signale fuer den Motor (analog) und den Laser (digital) in Einklang bringen kann. Wir wurde gesagt ich kann da was mit "streaming output" machen... ich weiss allerdings noch nicht wie das gehen soll?!?
Kann mir da jemand nen Tip geben wie ich an diese Sache rangehen kann, bzw. wo ich mich einlesen kann?
Besten Dank.
Tobs
(11.04.2011 23:17 )Tobs schrieb: [ -> ]Eine Hardwareloesung moechte ich erstmal noch nicht in betracht ziehen, solange ich nicht meine resorcen bis jetzt ausgeschoepft habe.
Bedenke aber (bereits im voraus), dass du viel Potential verschwendet haben wirst, wenn du später doch auf eine hardwarenähere Variante umsteigst.
Zitat:"streaming output"
Genau.
Theorie:
Auch ein Output, Kanal genannt, ist immer an ein Sampleraster gebunden. Wenn zu z.B. ein Raster von 10µs festlegst, macht das pro Sekunde 1E5 Werte (pro Kanal), die ausgegeben werden müssen. Diese Werte ergeben sich aus einer mathematischen Berechnung. Da beide Kanäle synchron laufen sollen, brauchen sie den selben Startzeitpunkt, das selbe Raster und die selbe Länge (und umgekehrt: haben sie alles drei gleich, laufen sie synchron). Durch entsprechende Mechanismen kann man einen Datensatz wiederholen lassen. D.h. die einmal für z.B. 1 Sekunde berechneten Werte gelten für alle weiteren Sekunden.
Erster Schritt zur Praxis:
In deinem Falle würde ich jetzt folgendes überlegen: Das Signal für den Laser ist ein digitales und das für den Motor auch. Du könntest also beide Kanäle in eine Task legen. Das hat den Vorteil: Es gibt nur eine Task und alles, was in einer Task liegt, läuft mit dem selben Raster. (Es ginge auch mit zwei Tasks. Nachteil: zwei Tasks, die auch noch synchronisiert werden müssen, was aber geht.)
Zweiter Schritt:
Raster festlegen. Reichen 2ms aus, so wage ich zu behaupten, dass die Samples mit einer While-Loop auf Applikationsebene ausgegeben werden können. Vorteil: Eine einfache Karte ist ausreichend. Liegt die Auflösung besser als 1000µs, muss du wohl eine Karte verwenden, die einen entsprechend großen Puffer hat. Die beiden Kanäle werden dann in die Karte geschrieben und die Karte übernimmt die schnelle Ausgabe (das geht dann aber bis zur maximalen Abtastrate).
...
Habe mir den Thread mal angesehen. Ich sehe hier nirgendwo eine Regelung.
Es laufen hier zwei unabhängige Aufgaben:
- Die Bewegung des Motors.
Hierzu wird einfach eine Rechteckspannung auf den Motor gegeben, wegen der Trägheit führt das zu einer annähernd sinusförmigen Bewegung. Der vorhandene Positionssensor wird nicht dazu benutzt, die Position zu kontrollieren. Unklar ist, wie man das langsame Wegdriften der Position verhindern will. Das ist ein zweifach integrierendes System ( 1. Integration: Motorstrom --> Drehzahl, 2. Integration: Drehzahl --> Winkelposition). Es handelt sich hier um keine Regelung. Und wegen der fehlenden Regelung wird die Position unvermeidlich driften.
- Ein-und Ausschalten des Lasers.
Bei bestimmten Positionen, gemessen mit dem Winkelencoder, soll der Laser ein- oder ausgeschalten werden. Das hat ebenfalls nichts mit eine Regelung zu tun. Hier ist lediglich eine schnelle und deterministische Reaktion gefragt, die allerdings mit dem normalen Windows-Labview eher nicht zu schaffen ist.
Das ganze Problem ist übrigens 1000fach gelöst, es gibt Firmen, die von Laserscannern leben. Als Motore dienen hier Galvanometer mit angeflanschtem Spiegel. Ein solches Galvanometer ist ein DC-Motor ohne Kommutator, der sich nur im Winkelbereich von typisch +- 22.5 deg drehen kann.
Besten Dank nochmal fuer eure Antworten!
(12.04.2011 08:07 )IchSelbst schrieb: [ -> ]Erster Schritt zur Praxis:
In deinem Falle würde ich jetzt folgendes überlegen: Das Signal für den Laser ist ein digitales und das für den Motor auch.
Ok... das hab ich erstmal so verstanden. Allerdings habe ich fuer den Motor ein analoges und fuer den Laser ein digitales (an/aus) Signal. Geht das dann auch so? Ich kann wenn es sein muss aber auch mit einem analogen Ausgang ein TTL Signal erzeugen, dass dann vom Laser wie ein digitales gewertet wird. Oder ist das dann langsamer? Der Laser muss naemlich wesentlich schneller geschaltet werden als der Motor!
(12.04.2011 09:43 )Lucki schrieb: [ -> ]Bei bestimmten Positionen, gemessen mit dem Winkelencoder, soll der Laser ein- oder ausgeschalten werden. Das hat ebenfalls nichts mit eine Regelung zu tun. Hier ist lediglich eine schnelle und deterministische Reaktion gefragt, die allerdings mit dem normalen Windows-Labview eher nicht zu schaffen ist.
Also kommt vermutlich doch nur der „Streaming output“ in Frage wenn ich Labview weiter verwenden moechte?!?
(12.04.2011 09:43 )Lucki schrieb: [ -> ]Das ganze Problem ist übrigens 1000fach gelöst, es gibt Firmen, die von Laserscannern leben. Als Motore dienen hier Galvanometer mit angeflanschtem Spiegel. Ein solches Galvanometer ist ein DC-Motor ohne Kommutator, der sich nur im Winkelbereich von typisch +- 22.5 deg drehen kann.
Genau. Das ganze ist nur auf eine etwas spezifischere Anwendung ausgelegt... naemlich auf ein Lasermicroskop wo die Optic noch etwas aufwendiger ist. Der einfachheithalber hab ich das bis jetzt noch nicht geschrieben.
Wer es genau wissen moechte:
Ich verwende auch eine Galvanometer mit angeflanschtem Spiegel zum scannen. Da man einen Laser auch nicht einfach so schnell aus und an schalten kann wird statdessen die Amplitude mithilfe eines Akustooptischen Modulators (AOM) moduliert. Ich schalte also mit Labview nicht direkt den Laser An und Aus, sondern den AOM, der dann den Laser fuer mich An und Aus schaltet. Am Ende soll eine gitterfoermige Beleuchtung einer Biologischen Probe mit einer Gitterkonstatnte von ca. 10 µm herauskommen bei dem ich die Phase, die Gitterkonstante und den prozentualen Anteil der Beleuchtung einstellen kann. Das alles soll dazu dienen die Aufloesung eines 3D Lichtschichtmikroskopes zu verbessern.
Danke.
Tobs
(12.04.2011 17:08 )Tobs schrieb: [ -> ]Allerdings habe ich fuer den Motor ein analoges und fuer den Laser ein digitales (an/aus) Signal.
Hab ich da was falsch interpretiert?
Wer steuert denn den Motor an? Machst du das von LabVIEW aus oder ist das komplett extern?
Ich bin bisher davon ausgegangen, dass du den Motor von LV aus ansteuerst. Nur dann wäre es machbar, wie ich es beschrieben habe: Nur wenn du das Motoransteuersignal kennst, würdest du auch den Laser ansteuern können - beide sollen ja synchron laufen. (Kennst du die MotorANSTEUERUNG nicht, musst du natürlich die aktuelle MotorPOSITION einlesen, um den Laser zu steuern).
Hast du denn jetzt mal eine Berechnung gemacht, wie genau die Steuerung des Lasers sein muss? Bei einer Ungenauigkeit von 100µs würde ich einer PC-Lösung ja noch verstehen. Bei 10µs erlaubter Ungenauigkeit würde ich aber zu einer Hardware-Lösung raten.