Ein Counter in Abhängigkeit vom anderen

Hi,

der Thementitel ist net so doll...aber mir ist nix besseres eingefallen:

Ich habe folgende Aufgabe:
Mit einem Counter erfasse ich TTL-Signale, die ein Drehzahlsensor liefert. Dieser Sensor detektiert über einen Hall-Sensor die Umdrehungen eines Polrades, auf das 48 Pole aufmagnetisiert sind. Pro Umdrehung kriege ich also 48 Impulse, daraus kann ich ganz einfach die Drehzahl berechnen. Soweit, so gut...das klappt prima.

Der Antrieb des Polrades erfolgt über einen Motor + FU, und auch die Umdrehungen des Motors kann ich über den am FU angeschlossenen Geber (bzw. über den FU-Ausgang "Gebernachbildung") als TTL-Signal erfassen.

Die eigentliche Aufgabe ist es, die Impulse des Polrades zu zählen in Abhängigkeit der Entfernung zwischen Polrad und Sensor. Wenn der Sensor nämlich weit genug vom Polrad weg ist, werden u. U. zu wenige Impulse pro Umdrehung der Antriebswelle generiert, d.h. es tritt ein Fehler auf. Ich muss also überprüfen, dass die 48 Impulse des Polrades, d.h. des Sensors (Ctr 1) innerhalb einer Umdrehung der Antriebswelle (Ctr 2) aufgetreten sind. Das ganze kommt so zustande das das Polrad eine Unwucht hat (im µ-Bereich) und wenn der Sensor der "tiefsten" Stelle des Rades gegenübersteht, wird aufgrund des zu großen Abstands kein Impuls generiert, kurz danach wird der Abstand durch die Drehung aber wieder kleiner und ein neuer Impuls kommt. Das ist aber dann nicht der Impuls, auf den ich eigentlich innerhalb einer Drehung der Antriebswelle gewartet habe, sondern schon der erste Impuls der neuen Umdrehung.

Hat jemand ne Idee, wie ich das bewerkstelligen kann? Hab ich mich verständlich ausgedrückt?

Bin für alle Vorschläge und Ideen dankbar...!

Gruß
Achim

Anzeige

Wie schnell dreht sich denn das ganze? Wenn es langsam genug ist, könnte man ja beide Counter in einer Schleife auslesen und als Abbruchkriterium 48 des Motor-Counters nehmen.
Ist nur eine Software-Lösung und nicht wirklich brauchbar bei schnellen Änderungen, aber erstmal besser als nichts.

Weitere Idee, aber vorerst keine Ahnung, wie das umzusetzen ist: Der Motor-Counter dient als Timer. Wenn 48 Pulse des Taktgebers (was in deinem Fall das Sensorsignal ist) vorüber sind, geht der Ausgang auf Low. Diesen Ausgang legst du nun (intern oder extern) an den Gate des anderen Counters. Der Counter sollte dann nur so lange zählen, wie das Gate High ist...
Vermutlich brauchst du dafür eine ähnliche Countereinstellung, wie in den Bilder hier:
http://www.LabVIEWforum.de/Hardware-getakt...sung-t7991.html

joh, das ist im Prinzip kein Problem, wenn du eine getriggerte Counter-Messung verwendest:

(ich geh jetzt mal von einer 6602 aus)
Counter 0: System-Takt der auf PXI_Trigg0 (oder RTSI0) geroutet wird
Counter 1: Encoder 1, continuierliche, gepufferte Messung, Zeitbasis PXI_Trigg0
Counter 2: Encoder 2, continuierliche, gepufferte Messung, Zeitbasis PXI_Trigg0

den Messtakt kannst du relativ klein wählen, z.B. 10 Hz oder, wichtig ist, dass die Zählerstände der beiden Counter 1 u. 2 jeweils immer exakt zum gleichen Zeitpunkt ausgelesen werden, und das schafft man nur in dem man sich den entsprechenden Messtakt selbst generiert.

die Triggerung:
(z.B.) den DIO0 auf PXI_Trigg1 routen, beide Encoder Tasks triggern auf PXI_Trigg1 und sind gestartet bevor du die Trigger-Leitung für ca. 5 ms auf high setzt

Für die Auswertung schaust du dir einfach immer das letzte Sample an und prüfst ob die Zähler-Stände gleich sind.

' schrieb:joh, das ist im Prinzip kein Problem, wenn du eine getriggerte Counter-Messung verwendest:

Hi Christian, das klingt ja schon ganz gut!

' schrieb:(ich geh jetzt mal von einer 6602 aus)
Counter 0: System-Takt der auf PXI_Trigg0 (oder RTSI0) geroutet wird
Counter 1: Encoder 1, continuierliche, gepufferte Messung, Zeitbasis PXI_Trigg0
Counter 2: Encoder 2, continuierliche, gepufferte Messung, Zeitbasis PXI_Trigg0

Zur HW:
Ich habe eine PXI-6602, PXI-6251, PXI-GPIB und ne PXI-CAN 8461

Zur Kommunikation mit dem restlichen Prüfstand sind aber leider die meisten der PFI als DIO verbraten, deswegen hab ich auf der 6602 keinen Ctr mehr frei. Die bisher geplante Aufteilung der Counter sieht so aus:

Ctr0: Gebernachbildung TTL(+) Flanke Ctr0 Gate: PXI-6602:PFI 38:3
Ctr0: Gebernachbildung TTL(-) Flanke Ctr0 Source: PXI-6602:PFI 39:2
Ctr1: Sensor TTL(+) Flanke Ctr1 Gate: PXI-6602:PFI 34:8
Ctr1: Sensor TTL(-) Flanke Ctr1 Source: PXI-6602:PFI 35:7

Ctr0: Sensor TTL(+) Periode Ctr0 Gate: PXI-6251:PFI 8:37
Ctr0: Sensor TTL(-) Periode Ctr0 Source: PXI-6251:PFI 9:3
Ctr1: Reserve(+) Ctr1 Gate: PXI-6251:PFI 3:42
Ctr1: Reserve(-) Ctr1 Source: PXI-6251:PFI 4:41

Mit dem Ctr1/6602 sollten die Sensorflanken gezählt werden, mit dem Ctr0/6251 sollte das (gleiche) Sensorsignal frequenzmäßig erfasst werden, um die Drehzahl zu ermitteln. Den Ctr0/6602 hab ich für das Gebersignal gemünzt, ich hab mir gedacht wenn die auf einer Karte liegen, sind sie leichter miteinander zu synchronisieren.

Tja, jetzt schlägst du vor das über einen dritten Counter zu machen. Kann ich dazu den Reserve-Ctr1/6251 verwenden und das Signal auf die anderen beiden Ctr routen? Geht das über RTSI? Wenn ja, was muss ich dafür genau machen, d.h. welche HW-mäßige Verbindung muss ich verklemmen?

Alternativ: Wenn ich die Flankenzählung im MAX auf "kontinuierlich" einstelle, kann ich als Typ des Sample-Taktes "Extern" (und nix anderes) einstellen, und dann als Taktquelle ein Signal auswählen. Wenn ich da jetzt beispielsweise PXI_Trig0 auswähle, muss ich dann den "Taktcounter" darauf routen? Wie geht das? Würde das so gehen (siehe Screenshot)? Und wie starte ich dann den Taktgeber-Counter?
   

' schrieb:den Messtakt kannst du relativ klein wählen, z.B. 10 Hz oder, wichtig ist, dass die Zählerstände der beiden Counter 1 u. 2 jeweils immer exakt zum gleichen Zeitpunkt ausgelesen werden, und das schafft man nur in dem man sich den entsprechenden Messtakt selbst generiert.

Ok, verstanden!

' schrieb:die Triggerung:
(z.B.) den DIO0 auf PXI_Trigg1 routen, beide Encoder Tasks triggern auf PXI_Trigg1 und sind gestartet bevor du die Trigger-Leitung für ca. 5 ms auf high setzt

Nicht verstanden...was meinst du hier mit Trigger? Das ganze soll ein kontinuierliche Messung sein, d.h. das Rad dreht dauernd und der Sensor liefert ständig Signale. Kann ich nicht "einfach" sofort mit der Messung starten, ohne das ganze irgendwie von außen anstoßen zu müssen? Siehe Frage "Start Taktgeber" weiter oben!

' schrieb:Für die Auswertung schaust du dir einfach immer das letzte Sample an und prüfst ob die Zähler-Stände gleich sind.

Wenn ich nur schon so weit wäre...

Noch ne Info zu den Drehzahlen: Der Antrieb läuft mit bis zu 3000 rpm!

Gruß
Achim

Hi Christian,

ich glaube, beim letzten Beitrag hab ich was missverstanden, deswegen hier ne Änderung, die hoffentlich dem entspricht, was du gemeint hast.

Also, ich erzeuge einen Takt mit Ctr 6251/1, den route ich auf PXI_Trig0 (siehe im linken Screenshot oben links).
       

Diesen PXI_Trig0 nutze ich als Zeitbasis für die beiden Flankenzählungen (siehe die beiden folgenden Shots):
       

Die Messung starte ich, indem ich beide Zählungen mit dem PXI_Trig1 triggere, diesen Triggereingang hole ich mir z.B. dadurch, dass ich einen DO auf PXI_Trig1 route (siehe im obersten Screenshot oben rechts)! Das wäre dann ein "interner Start"...man könnte das auch über ein externes Signal auf einem DI machen?!

Könnte ich mir den letzten Schritt, d.h. das Routing eines DO auf PXI_Trig1 sparen, indem ich direkt den DO als Trigger für die Flankenzählungen konfiguriere (siehe zweite Konstante beim Routing (nicht angeschlossen))?

Gruß
Achim

sieht im Prinzip schon ganz gut aus, aber es fehlen noch ein paar Kleinigkeiten / Antworten:

Ja, du kannst auch den Reserve Counter verwenden um den Messtakt zu erzeugen. Es ist aber einfacher wenn du alle Tasks auf einer Karte verwendest, dann brauchst du kein RTSI Kabel. Wenn du ein PXI Chassis verwendest, dann ist es natürlich schon vorhanden und du musst dir darüber keine Gedanken mehr machen. Du könntest sogar - die entsprechende Messkarte (die muss das halt können) - einen cont. digital Pulse Train verwenden, ich würde das aber nur als Notlösung ins Auge fassen, weil ich im Moment keine Ahnung habe, wie genau das Timing dabei ist.

Ich weiß nicht genau, ob man einen DI auf die Backplane durchrouten kann. Das müsstest du einfach mal ausprobieren. Generell kann man aber mit der 6602 beim Routing ganz wilde Sachen machen:)Die Schwierigkeit ist, dass der Anschluss immer auf der 6602 sein muss. Woher soll die Karte sonst wissen, was der Trigger ist, sie kann ja nur ihre eigenen elektrischen EAs verwenden ...

Die Kontinuierliche Messung sollte kein Problem sein. Wenn du nicht permanent auswerten willst kannst du dir ja einfach jeweils den letzten Stand von der Drehzahl-Erfassung in einer Old Style Global speichern und die Daten nur dann auswerten, wenn es dich interessiert. Andererseits hast du - wenn du die Erfassung - nur einmal startest das Problem, dass du dann immer mit den "alten" Zählerständen weiter arbeitest. Da ist es ggf. einfacher die Tasks zu beenden und dann neu zu starten und alles steht wieder auf 0.

Ich hab mal ein paar Screenshots von meiner (aktuell) 10-fach Drehzahl-Erfassung mit 2 PXI-6602 gemacht:

1. Messtakt erzeugen
   

2. Trigger Task erzeugen
   
ich verwende hierfür einfach den DIO0 der 6602 ...

3. Tasks für die Winkelpositions-Messung erzeugen
   
wichtig ist dabei, dass man nicht das Standard DAQmx Trigger-Einstellungen VI verwendet, sondern dass man wie im Bild die Property Node verwendet, das Standard VI funktioniert hier nicht. Ich muss hier als Datenübertragungs-Mechanismus IRQs setzen, weil ich keine 10 DMA Kanäle im Rechner habe

4. Digitalen Trigger senden
   
ich denke dass man hier auch einen x-beliebigen anderen (externen) Digitalen Puls verwenden kann, wichtig ist nur, dass er rechtzeitig kommt. Wenn man ein bisschen basteln möchte, und einer der Encoder ein Z-Signal hat könnte man auch das elektrisch auf einen DI legen, entsprechend routen und den verwenden. Der Trigger wird wie gesagt nur benötigt, damit die Tasks gleichzeitg loslaufen. Da sie ein und denselben Messtakt verwenden ist somit sichergestellt, dass sie absolut synchron laufen ...

5. Samples Lesen und Drehzahl ermitteln
   
wobei ich den Verdacht hab, dass ich mich hier noch irgendwo verrechnet hab ...

das "Aufräumen" hab ich nun nicht als SC gepostet:
- Tasks schließen, Routing aufheben ...

Hi Christian,

erst mal danke für die ausführliche Antwort! Ein paar Fragen noch...

Ich hab das ganze jetzt mal nachgebaut mit allen drei Countern auf einer Karte. Das funktioniert gut! Wenn ich allerdings den "Taktgeber-Counter" auf der 6251 habe, kann ich mit meinem Chassis PXI-1033 offenbar die Triggerleitungen nicht Kartenübergreifend routen. Ich kann sie zwar auswählen, kriege aber immer ne Fehlermeldung (siehe Screenshot). Wo kann ich denn definitiv nachprüfen, welche Möglichkeiten es da gibt? Ich hab schon mal in den Handbüchern geschaut, finde aber da nix wesentliches...

   

Zitat:Für die Auswertung schaust du dir einfach immer das letzte Sample an und prüfst ob die Zähler-Stände gleich sind.

Aha...wie meinst du das? Ich muss gestehen, mir ist bei ner Countermessung nicht so richtig klar, was die "Number of samples in the buffer" eigentlich bedeutet. Bei ner Analogmessung sind das ja die durch die Abtastung aufgelaufenen Werte...wie ist das bei ner Countermessung? Wird da durch die Abtastung u.U. halt mehrfach der gleiche Zählerstand erfasst und dieser dann in den Buffer gelegt? Welcher Wert ist dann "das letzte Sample"? Der Wert 0 im Buffer-Array?

Zur Messung:
Ich habe durch die Anzahl der Impulse vom FU-Geber (1024) und eigentlichem Sensor (48) ein theoretisches Verhältnis von 21,3333....
Bei höhreren Drehzahlen ergibt sich dieses Verhältnis auch bei meiner Messung, allerdings erst nach einer gewissen Messdauer und mit zappelenden Kommastellen. So nach etwa 20 Sekunden steht das Verhältnis bei ca. 21,33xx. Das da in der Realität nicht genau das theoretische Verhältnis rauskommen kann, liegt wohl auch daran, dass die "Polgrenzen" der beiden Impulsgeber niemals 100%ig übereinander liegen werden, oder? Wann (nach welcher Zeit? nach wie vielen Umdrehungen?) kann ich aber sagen, das mein Messwert genau genug ist?

Für die Auswertung sollen beispielsweise die Messwerte/Zählerstände der letzen X (z.B. 10) Umdrehungen herangezogen werden. Wie kann man das geschickt lösen? Wie trenne ich überhaupt die Umdrehungen voneinander?

Für weitere Anregungen wäre ich dankbar...vielleicht hat ja auch der "alte" Physiker Jens G mal ein paar Tips theoretischer oder praktischer Natur?

Gruß
Achim

Zitat:Wenn ich allerdings den "Taktgeber-Counter" auf der 6251 habe, kann ich mit meinem Chassis PXI-1033 offenbar die Triggerleitungen nicht Kartenübergreifend routen. Ich kann sie zwar auswählen, kriege aber immer ne Fehlermeldung (siehe Screenshot). [attachment=37253:error.PNG]

Ouuuhhhhhhhhhhh...bin ich doof! Das hab ich jetzt hingekriegt...ich hab immer von Ctr0/Slot3 nach PXI_Trig0/Slot4 routen wollen...das ist aber Quatsch...man muss natürlich von Ctr0/Slot3 nach PXI_Trig0/Slot3 routen, und damit steht dieses Signal über den TriggerLine-Bus natürlich auch den anderen Slots zur Verfügung...tststs...sowas...

Beim Rest meines letzten Beitrags bin ich aber noch nicht weiter gekommen...

Gruß
Achim

die Fehlermeldung sagt eigentlich schon alles:

mach den MAX auf und sag dem DAQ dass es sich bei deinem "unidentified PXI Chassis" um ein 1033 handelt. Dann kann DAQmx auch was mit dem Alias PXI_TRIGG0 was anfangen.

Letztes Sample im Buffer:
Angenommen du hast eine Abtastrate von 100 Hz eingestellt und du holst immer einen Block von 10 Samples ab, dann hast du eine Schleifendurchlaufzeit (hardware-getimed) von 100 ms und du bekommst zwei Arrays mit jeweils 10 werten Zurück.

Element mit dem Index 9 ist das - zeitlich gesehen - aktuellste Sample, Index 8 war vor 10 ms, index 7 vor 20, Index 6 vor 6 usw. Da du dich ja immer nur der aktuelle Stand interessiert um die Frage zu klären "Ist da was aus dem Takt oder zählen beide noch gleich", reicht es die jeweils letzten Samples (Index 9) miteinander zu vergleichen.

Da die Beiden Tasks über einen Trigger gestartet wurden kann es eigentlich nur noch sein, dass der Unterschied zwischen den beiden Zählerständen genau einen Tic beträgt.

Andere Möglichkeit: du subtrahierst beide Arrays voneinander und überprüfst ob sich die Differenz mit dem Index 9 gegenüber dem letzten Schleifendurchlauf geändert hat. SO gewinnst du auch die Information ob der Prüfling nicht mehr richtig zählt.

Drehzahlen bis 3krpm sind kein Problem, 30krpm wären auch keines ... schon gar nicht bei 48 Impulsen.

Fehler gemacht...