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!
zur Zeit empfange ich Sensordaten über Module in einem CRio und berechne daraus Stellsignale für ebenfalls an das CRio angeschlossene Aktoren. Da ich das analoge Stellsignal des PID-Reglers in ein PWM-Signal wandeln möchte, benötige ich die Dauer, genauer gesagt, die Anzahl der Ticks pro Schleifendurchlauf. Wenn ich einfach die Differenz aus dem Ausgabewert von Tick Count und dem vorangegangenen Ausgabewert von Tick Count nehme, komme ich immer auf 29127,1 Ticks pro Durchlauf. Um herauszufinden welcher Programmteil auf der FPGA zu dieser Verzögerung führt, wollte ich die Laufzeiten einzelner Teile (die sonst parallel ausgeführt werden) mit Tick Count wie oben beschrieben bestimmen und habe mit der Tick-Countfunktion an sich angefangen, da ich dachte, dies sei ein sehr schnell auszuführendes kurzes Programm. Nur dieses liefert mir einen 3 stelligen Millionenwert an Ticks pro Schleifendurchlauf, was bei 40 MHz des FPGA wohl nich sein kann.
1. Dauert die Verwendung der Tick Count also wirklich so lange, oder habe ich etwas falsch eingestellt oder Tick Count nicht sinngemäß verwendet, dass es zu so vielen
Ticks pro Durchlauf kommt?
2. Wenn Tick Count die Ausführung ausbremst, wie bekomme ich dann die Ticks pro Schleifendurchlauf heraus?
Im Anhang das VI zur Messung der Ticks pro Schleifendurchlauf ( nur die obere Schleife beachten). "Differenz Ticks" und "Numerisch" zeigen die hohen Werte.
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
RE: Schleifendauer unerwartet hoch
Mal unabhängig des FPGA-Problems (damit kenne ich mich nicht aus).
Wieso hast Du keine Zeitverzögerungen in Deiner Whileschleife? Hast Du Dir schon mal die CPU-Last in diesem Fall angesehen?
Gruß Markus
-------------------------------------------------------------------------- Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
(24.01.2012 07:31 )Y-P schrieb: Wieso hast Du keine Zeitverzögerungen in Deiner Whileschleife? Hast Du Dir schon mal die CPU-Last in diesem Fall angesehen?
Ein FPGA hat keine CPU, man könnte vielleicht eher sagen, der ganze FGPA-Chip ist die CPU. Alles, was parallel programmiert ist, läuft auch echt parallel ab, mit der Taktfrequenz des FPGA. Genau das will man in der Regel. Waits sind nicht unbedingt nötig.
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!
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
RE: Schleifendauer unerwartet hoch
Danke für die Info. Jetzt weiß ich das auch.
Gruß Markus
(24.01.2012 08:33 )jg schrieb:
(24.01.2012 07:31 )Y-P schrieb: Wieso hast Du keine Zeitverzögerungen in Deiner Whileschleife? Hast Du Dir schon mal die CPU-Last in diesem Fall angesehen?
Ein FPGA hat keine CPU, man könnte vielleicht eher sagen, der ganze FGPA-Chip ist die CPU. Alles, was parallel programmiert ist, läuft auch echt parallel ab, mit der Taktfrequenz des FPGA. Genau das will man in der Regel. Waits sind nicht unbedingt nötig.
Gruß, Jens
-------------------------------------------------------------------------- Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
Hallo,
das liegt wohl darin, dass du einen kleinen Denkfehler in deinem Programm hast. Momentan ziehst du in jedem neuen Schleifendurchlauf die letzte Counterdifferenz vom aktuellen Counterwert ab, ich denke nicht, dass es so gedacht war. Damit ziehst du immer nur kleine Werte von dem Aktuellhohen Counter ab und die Differenz ist somit sehr groß. Im ersten Schleifendurchlauf müsste das Ergebnis bei dir trotzdem richtig sein (da ja mit 0 initialisiert) aber jeder weitere Durchlauf bringt das falsche Ergebnis.
Um korrekt den letzten Counterwert vom aktuellen abzuziehen, musst du den Counter direkt an den Tunnel anschließen und nur den Indikator an der Differenz dran lassen, siehe Anhang.