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 hab in meinem Vi alles über den DAQ _ Assistenten gemacht. Nur kann ich da keinen Trigger einstellen oder den Counter auf implicit stellen, damit er alle Perioden zählt.
ist es generell sinnvoller, gleich zu Beginn alles selbst aus den Bausteinen aufzubauen?
Wahrscheinlich ist es auch schlecht, wenn ich die Nachlaufzeit über die Schleifendurchlaufzeit bestimme, sondern über die gemessenen Periodendauer aufsummiere. Dazu muss ich aber sicherstellen, dass auch alle detektiert werden.
Noch eine Frage hätte ich:
Wenn ich in meine Ereignisstruktur: Kennlinie komme, durchlaufe ich eine while-schleife, bis die Geschwindigkeit unter 0,1mm/s abgefallen ist.
danach gebe ich Kennwerte aus.
Wenn ich danach nochmal eine Kennlinie aufnehmen will, sind die Werte noch in den Feedback nodes gespeichert, die ich benötige. Kann man die irgendwie löschen?
Oder ist es besser die Geschwindigkeit aufzunehmen, mit einer gewissen Frequenz zu sampeln (z.b. 10KHz) und diese abzuspeichern, bis die while-schleife beendet wird.
da weiß ich aber nicht, wie ich das am besten machen soll, da mir der DAQ-Assistent immer nur den aktuellen Wert anzeigt?
(18.07.2014 11:40 )amadeus schrieb: Ich hab in meinem Vi alles über den DAQ _ Assistenten gemacht. Nur kann ich da keinen Trigger einstellen oder den Counter auf implicit stellen, damit er alle Perioden zählt. ist es generell sinnvoller, gleich zu Beginn alles selbst aus den Bausteinen aufzubauen?
ich nehm den DAQ-Assistenten immer um mir ein Grundgerüst erstellen zu lassen, zerfledder das ganze dann und bau die Feinheiten ein. Der Assistent ist schon nicht schlecht, aber man kann den auch nie so allumfassend Programmieren, dass er auch die letzte Feinheit kennt. Außerdem ist es mMn auf jeden Fall erforderlich, dass man das, was der Assistent macht auch selber programmieren kann, sonst kommt sowieso nur Murks raus. Ohne Ahnung von der Technologie, die dahinter steckt, mit einem Assistenten zu dem richtigen Ergebnis zu kommen ist wie Lotto spielen, kann klappen, meistens klappts aber nicht.
(18.07.2014 11:40 )amadeus schrieb: Wahrscheinlich ist es auch schlecht, wenn ich die Nachlaufzeit über die Schleifendurchlaufzeit bestimme, sondern über die gemessenen Periodendauer aufsummiere. Dazu muss ich aber sicherstellen, dass auch alle detektiert werden.
dann brauchst du wieder einen kontinuierlichen Task, aber das ist mit dem Example-Finder auch kein Problem. Du kannst dich aber auf jeden Fall darauf verlassen, dass sowohl bei einem finiten, als auch bei einem kontinuierlichen DAQmx-Task der zeitliche Abstand zwischen 2 Samples im Array 1/Sample-Rate entspricht (also bei 1 kHz Sample-Rate ist der Abstand zwischen 2 Samples = 1 ms!!!) und das ist die genaueste Uhr, die dir in der Software zur Verfügung steht. Die Wait-Timer und ggf. auch Timed Loops im Source-Code sind alles nur Uhren, die mehr oder weniger trickreich in Software von der CPU-Zeit abgeleitet werden und das kann nie so genau sein wie ein Hardware-Timer!
Gerade wenn es beim Messen auch um Zeiten geht, ist es mMn absolut erfolderlich entweder einen kontinuierlichen DAQmx-Task oder einen finiten Task zu verwenden, nur so kann man sich sicher sein, dass bei einer SR von z.B. 1 kHz das 500. Sample genau 500 ms. Sekunden nach dem 1. Sample erfasst wurde! Und da du bei deiner Problemstellung einen Weg im Bezug zu einer Zeit setzen musst um daraus eine Geschwindigkeit zu ermitteln (v = ds/dt!) brauchst du hier auch eine genaue Zeit-Messung. Ok, dass die Zeit implizit in der Position des Samples im Rückgabe-Array steckt ist gerade für Anfänger erst mal nicht offensichtlich, aber genau darum sag ich's dir ja
(18.07.2014 11:40 )amadeus schrieb: Wenn ich danach nochmal eine Kennlinie aufnehmen will, sind die Werte noch in den Feedback nodes gespeichert, die ich benötige. Kann man die irgendwie löschen?
da weiß ich aber nicht, wie ich das am besten machen soll, da mir der DAQ-Assistent immer nur den aktuellen Wert anzeigt?
Schau mal in die LabVIEW Hilfe - Feedback-Nodes und Shift-Register kann man von "aussen" und "innen" initialisieren. Von aussen geht automatisch wenn man was anklemmt, von innen geht z.B. über eine Case-Struktur, o.ä.
(18.07.2014 11:40 )amadeus schrieb: weiß ich aber nicht, wie ich das am besten machen soll, da mir der DAQ-Assistent immer nur den aktuellen Wert anzeigt?
Nehmen wir mal ein einfaches Beispiel: ein ungetriggerter continuierlicher Counter-Task, mit einer Sample-Rate von 1 kHz und einem konstanten Eingangs-Signal, das mit 10 kHz toggelt. Dafür erstellst du mit dem DAQ-Assistenten einen kontinuierlichen Flanken-Zähl-Task, der immer einen Block von 100 Samples am Stück ausliest. Damit die 100 Samples erfasst werden können muss der Task 100 ms lang samplen, erst dann spuckt er den Block mit 100 Werten taus.
Weil so ein kontinuierlicher Counter-Task (zumindest auf der 6259, die ich gerade da habe) eine externe Takt-Quelle für den Sample-Takt braucht nimmt man z.B. eine analoge Erfassung mit dazu, braucht man ja sowieso fast immer. Die beiden Tasks verknüpft man über den AI/StartTrigger, dann laufen sie auch beide synchron:
Wenn du das nachprogrammierst, dann musst du eigentlich nur noch in der While-Schleife die Daten aus dem Counter-Task auswerten und aus den Flanken eine Drehzahl bzw. Geschwindkgeit errechnen und dir was einfallen lassen wie du die Daten speicherst. Mit "last element" habe ich angedeutet, wie du an den jeweils neuesten Wert deiner Messwert-Erfassung kommst. Statt dem Flanken-Zähl-Task kannst du aber auch einen Encoder-Task nehmen, der dir dann auch gleich eine Drehzahl ausspucken kann, aber das überlass ich dir zum experimentieren
Ich stelle eine Sampelrate von 1kHz ein, was bedeutet, dass ich jede ms mein Eingangssignal Abtaste. Diese Werte werden in einem Buffer gespeichert, aus dem ich sie mir dann in
von mir ausgewählten Paketen auslesen kann. So wie in deinem Bsp immer zu 100 Werten, was einer Messzeit von 100 ms entspricht. Diese Werte habe ich dann in einem Array gespeichert.
Dieses 100 Samples übergebe ich dann an meinen Countertask, welcher die Flanken zählt.
Angenommen ich nehme jetzt die Anzahl der Flanken, Multipliziert mit 1e-4, was dann dem zurückgelegten weg entspricht und dividiere durch 100ms=0,1, dann bekäme ich die über 100ms gemittelte Geschwindigkeit, weil ich davon ausgehen kann, dass die Zeit der 100ms konstant sind?
Natürlich wäre das viel zu ungenau, aber nur für mein Verständnis?
Für die Nachlaufzeit würdest du also die Anzahl der Samples einfach mit 1ms multiplizieren?
Könntest du mir noch erklären, warum es nicht funktioniert, dass ich meine einzelnen Periodendauern aufsummiere? Ich habe nämlich bei den Examples gelesen, dass ich mit dem Implicit Timing jede Periodendauer erfassen. Ich also keine "übersehe". Oder summiere ich hier einfach nur immer die Periodendauer auf, die gerade vorliegt, wenn ich die Schleife durchlaufe?
Die Hilfe vom Feedback Node hab ich mir jetzt schon 3 mal durchgelesen, aber immer noch nicht verstanden, wie ich es mache, dass die Werte immer dann auf 0 gesetzt werden, wenn ich die While-Schleife zum ersten mal durchlaufe!
Ich schaus mir jetzt nochmal an
(21.07.2014 09:51 )amadeus schrieb: Dieses 100 Samples übergebe ich dann an meinen Countertask, welcher die Flanken zählt.
nö, was soll der auch damit?
Bei einem Counter-Task stellst du einen Counter auf der Messkarte so ein, dass er zäht, und zwar die Events (z.B steigende Flanken), die am Counter-Eingang (bzw. Eingängen je nach dem wie du deinen Task konfiguriert hast) anliegen. Das macht der Zähler-Baustein sozusagen vollautomatisch im Hintergrund.
Mit einem kontinuierlichen Counter Task fragst du in regelmäßigen Abständen (=deiner Sample-Rate) den Zähler-Stand ab. Stell dir einfach vor, du rennst 1000 mal die Sekunde zum Strom-Zähler und liest den Zähler-Stand ab, und jenachdem wie viel Strom du gerade verbrauchst steigt der Zähler-Stand von Sample zu Sample entweder schneller oder langsamer.
Der Strom-Verbrauch pro Sekunde wäre nun also Zählerstand von Sample 1000 minus Zählerstand von Sample 1 durch 1 Sekunde. Oder wenn du den Strom-Verbrauch alle 100 ms haben willst Zählerstand(100) minus Zählerstand(1) durch 0,1 Sekunden. Und wenn du das so machst wirst du feststellen, warum ich in meinen Postings weiter oben erwähnt habe, du sollst einen gleitenden Mittelwert von min. 500 ms drüber legen, weil du - um bei diesem Beispiel zu bleiben - etwas kleines (kurze Block-Zeit = weniger Differenz zwischen Anfang und Ende) durch eine kleine Zeit teilst, was bei kleinen Änderungen im Zähler (z.B 1 Tic mehr oder weniger) zu großen Ausschlägen führt ...
Der Kniff mit dem Analogen Eingangs-Task wird nur gebraucht weil deine Messkarte vermutlich keinen RTSI oder PXI-Bus hat und es evtl. sonst knifflig wird für das periodische Auslesen des Zählerstandes einen Takt zu erzeugen, man aber eigentlich auf jeder Messkarte den die AI-scan-clock durch das Subsystem der Karte routen und weiter verwenden kann ...
Ich habe jetzt versucht deine Ratschläge umzusetzen, nur leider ist mir das nicht gelungen.
Ich habe versucht die Periodendauer und die Flankenzählung mit 1000 Hz Sample-Rate, also jede ms einen Wert, abzutasten.
Diese Werte würde ich jetzt zu Beginn einfach einmal in ein Measurement-File speichern und zwar so lange, bis die Periodendauer ein Maximum von 1s erreicht hat!
Für Die sample-Clock habe ich, wie du gesagt hast, das Signal auch am Analogen Eingang Ao eingelesen.
Wenn ich versuche die Periodendauermessung und die Flankenzählmessung auf dieses Analoge Eingangssignal zu Triggern, dann bekomme ich bei beiden den Fehler "ERR 200452"
Lasse ich den Trigger weg, dann Läuft der Counter bis 1002 hoch und bricht dann mit der Fehlermeldung:
ERR 201314
Multiple Sample Clock pulses were detected within one period of the input signal. Use a Sample Clock rate that is slower than the input signal. If you are using an external Sample Clock, ensure that clock signal is within the jitter and voltage level specifications and without glitches.
die Periodendauermessung funktioniert nicht. Der Fehler tritt auch bei der Periodendauermessung nach dem Read-Task auf.
Wenn ich dann bei der Periodendauermessung auf Implicit-time stelle, dann läuft die Periodendauermessung auch ab. Nur bricht die Messung weder ab, wenn ich über 1000 Flanken gezählt habe, noch die Periodendauer über 1s beträgt. Lediglich nach gewisser Zeit kommt der
Error 200279
Attempted to read samples that are no longer available. The requested sample was previously available, but has since been overwritten.
Increasing the buffer size, reading the data more frequently, or specifying a fixed number of samples to read instead of reading all available samples might correct the problem.
Deine Erklärungen erscheinen mir immer logisch und einleuchtend, aber irgendwie funktionieren meine Umsetzungen nicht wirklich!
könntest du mir da bitte noch einmal helfen?
freundliche Grüße
Amadeus
22.07.2014, 10:50 (Dieser Beitrag wurde zuletzt bearbeitet: 22.07.2014 10:50 von amadeus.)
Nach weiteren 2 h tüfteln bin ich jetzt soweit, dass ich Werte einlesen kann.
Ich habe jetzt eine Sample Rate von 40 kHz eingestellt, was eigentlich immer noch zu wenig ist, wenn man bedenkt, dass ich eine Maximale Frequenz von 100 kHz bei 10m/s Geschwindigkeit erreichen kann.
da müsste ich mit 200kHz Samplen. Beim simulieren mit maximal 20kHz genügen die 40kHz jedoch, nach Shannon!
Die "Samples per Channel" sind ja eigentlich nur die Anzahl der Samples die ich in meinem Buffer speichern kann. Da hab ich mir einfach mal 1Mio reserviert.
Diese Speichere ich dann nachdem ich alles aus dem Buffer ausgelesen habe in ein Excel -file. Soweit funktioniert das, meiner Meinung nach , schon einmal ganz gut.
Das Triggern habe ich leider noch immer nicht hingebracht.. wenn ich meine Messung starte, bekomme ich meine COunterstände leider nicht von 0, sondern, bei 20kHz etwa ab dem 600 Inkrement.
ich leg mein VI mal in den Anhang, vielleicht hast du ja Zeit es dir einmal anzusehen!
Habe das mit dem Trigger hinbekommen. Außerdem speichere ich immer, wenn die Messung beendet wird, alles in ein Excel-File, das funktioniert schon einmal.
nur weiß ich nicht, warum ich bei der Periodendauermessung die Zeiteinstellung nicht auf Sample Clock einstellen kann, ohne einen Fehler ERR 201314 zu bekommen.
Die funktioniert nur mit der Implicit-time Einstellung. Aber da bekomme ich dann ja nicht meine Samples mit der eingestellten Sample-Rate, oder?
Auch die Zeitmessung über die Anzahl Samples/Samplerate schaut sehr gut aus.
Frage 1:
Damit ich an die Zeit komme, lese ich derzeit alle Samples in eine Excel-Datei, welche ich immer überschreibe, wenn ich die Messung neu ausführe. Diese Verknüpfe ich mit einem anderen Excel-File, in welcher ich
nur die Anzahl der Samples/Samplerate stehen habe. Und diesen Wert importiere ich wieder in Labview.
Meine Frage: geht das irgendwie einfacher, dass ich in Labview schon an die Anzahl meiner Samples komme?
Frage 2:
Warum ich bei der Periodendauermessung nicht mit der Sample-Clock arbeiten kann?
/
Drehgeber Datenerfassung DAQmx.9.8 Nachlaufmessgerät
