Hallo puh,
noch ein kleiner Nachtrag: wenn man die Methode mit dem Addieren eines Offsets für die Phasenverschiebung umsetzt, muss man noch eine Modulo-Operation hintendran packen, um im erlaubten Counter-Bereich (im Beispiel 120) zu bleiben. (Beispiel: Kanal1 ist bei 110, Kanal2 dann schon bei 110+20: 130 MOD 120 = 10.)
Vielen Dank für den Nachtrag. Ich hatte mir heute schon ein wenig den Kopf zerbrochen, wie ich das am "simpelsten" lösen kann, da ich ja nur von 0-180° Phasenverschiebung problemlos addieren kann. An die Restwert Division hatte ich noch garnicht gedacht.
Ich habe die Phasenverschiebung mittlerweile getestet. Für Phasenverschiebungen Delta.phase >= 0, funktioniert schon alles einwandfrei. Auch, wenn ich eine Phasenverschiebung >180° einstelle, funktioniert (z.B.: Amplitude Dreieck: 20 Ticks / Phasenverschiebung: 270° => 30 Ticks --> 30 Modulo 20 = 10 / Addition +10 & Umschalten auf fallende Flanke).
Sobald meine Phasenverschiebung (Delta.phase1 => muss eigentlich phase1 heißen) kleiner als 1 wähle, springt aber komischerweise mein Counter (Ticks N1) auf den Maximalwert (4294967). Aktuell habe ich keine Ahnung, was da wirklich gerade schief läuft. Weitere Details, siehe Anhang.
Ein weiteres Problem habe ich, dass ich die Phasenverschiebungsänderung (Delta.phase1) gerne bei Ausführung des Case-Befehls einmalig mit sich selbst subtrahiere, um den Wert 0 zu bekommen (z.B.: Addition +10 Ticks -> danach Subtraktion mit sich selbst => 0 und somit keine weitere Phasenverschiebung; erst bei Änderung des Wertes). Das funktioniert aber derzeit nicht.
Vielen Dank im voraus und schönes Wochenende.
LG
Hallo puh,
das blöde suboptimale an Bildern ist, dass sie sich mit LabVIEW so schlecht debuggen lassen…
Häng doch mal dein VI an!
Hallo Gerd,
da gebe ich dir Recht. Mein "Test"-VI, den ich auf meinem Rechner gerade ausprobiere, habe ich mal hochgeladen.
*EDIT*
Der Fehler mit dem Counter trifft ebenfalls auf, wenn die Phasenverschiebung größer als die Amplitude des Dreiecksignals ist.
Fehler gefunden und behoben!
Ich rechne beim Counter-Wert "0" über ein Inkrement "-1", wenn die Phasenverschiebung über 180° ist. Dadurch springt der Wert von 0 auf 4.294.967.289.
In den letzten Tagen habe ich einige Dinge abarbeiten können. Leider bereitet mir das Einbinden der Phasenverschiebung noch so ein paar Probleme. Zuletzt wollte ich über den RT die Phasenänderung (Delta.phi) per DMA auf meinen FPGA übertragen. Dort kam aber die Vermutung auf, dass ich für mehrere Zyklen diesen Delta.phi übertrage, obwohl ich nur eine einzige Änderung vornehmen wollte (Zykluszeit vom RT >> FPGA).
Daraufhin habe ich die Berechnung der Phasenänderung auf den FPGA umgelagert, womit sich das Problem bzgl. der Zykluszeit beheben sollte. Ich übertrage vom RT also nur noch die aktuelle Phasenverschiebung (z.B. phi1=180°) und nicht die Änderung (delta.phi). Auf dem FPGA habe ich die Änderungen vorgenommen und den Programm daraufhin kompiliert.
Aktuell habe ich folgende Probleme:
1. Die Phase verschiebt sich bei positiver Phasenverschiebung dauerhaft (Signal schwimmt --> Phase verschiebt sich dauerhaft, bis Wert "phi1" wieder auf 0 gesetzt wurde)
2. Bei negativer Phasenverschiebung lässt sich die Phase verschieben, allerdings wird bei -180° Phasenverschiebung auf beiden Phasen, die beiden Signale (die bei 0° vorher identisch übereinander lagen) nicht mehr gleich überlagert (-> Versatz des Signals). Wieso ich nur negative Phasenänderungen durchführen kann, erschließt sich mir bisher noch nicht.
Die Grundidee ist, dass ich die Phasenverschiebung immer nur beim 0-Durchgang vom Counter Signal, durchführe.
Habt ihr einen Rat oder evtl. auch eine Idee, wie ich die Phasenverschiebung sauber umsetzen kann und woran das Problem mit dem Versatz & der (nur möglichen) negativen Phasenänderung herkommt?
P.S.: Im unten eingefügten Test.vi ist die Programmierung nur für ein Signalpaar (Halbbrücke) programmiert. Auf dem FPGA habe ich die Signale natürlich dupliziert (für Vollbrücke bzw. 2 Halbbrücken), um den Vergleich zwischen zwei phasenverschobenen Signalen betrachten zu können.