Zeitverzögerung zwischen parallelen Schleifen - ungewollt!

Hallo zusammen,

ich habe eine Regelung realisiert, die über den Öffnungswinkel von Schwingfenstern die Temperatur in sechs Häusern konstant hält. Das läuft soweit, aber cRIO zeigt ein ungewolltes Verhalten. Es gibt zwei zentrale Taster (Mod3/DI12 und DI13), über die manuell alle Fenster synchron geöffnet oder geschlossen werden können. Sobald ein Taster gedrückt wird, geht der Regler aus und jedes Fenster bewegt sich. Werden beide Tasten zeitgleich gedrückt, wird die Regelung wieder eingeschaltet. Gut soweit. Aber ich habe eine ungewollte Verzögerung: drücke ich einen Taster, beginnen die Fenster nacheinander mit der Bewegung; es dauert gut eine halbe Sekunde, bis das alle tun. Nach Loslassen das gleiche, erst nach einer guten halben Sekunde stoppen wirklich alle. Nicht schlimm, aber unbefriedigend. Ich sehe den Wald vor lauter Bäumen nicht mehr, habe ich doch irgendwo Race Conditions eingebaut? Oder liegt's an den lokalen Variablen?
Anbei das FPGA-VI, heruntergestrickt auf die problematischen Funktionen. Habe alles rausgenommen, was parallel war und nichts mit den verwendeten Variablen zu tun hat...

Grüße
Roland

Hi,

ich werde aus einigen Dingen nicht so recht schlau. Du fängst viele unsinnige Nutzereingaben merkwürdig ab (z.B. in den einzelnen Haus-Schleifen), die es zumindest mir schwierig machen, das zu verstehen.

Zu Deiner Frage mit lokalen Variablen: m.E. werden für den FPGA globale Variablen aus Effizienzgründen empfohlen. Das könnte schon sein, dass das häufige Aufrufen zusammen mit den Waits sich entsprechend aufaddiert. Warum hast Du eigentlich Waits in Deinen Schleifen? Da der FPGA echt parallel arbeitet, braucht man die eigentlich nicht. direkte Nutzereingaben auf dem FP gehen auch nicht im Live-Betrieb, daher sind die m.E. unnötig. (BTW: Wie bedienst du das ganze? Wenn du direkt das FP des FPGA bedienst und nicht über das RT-Target ist die Performanz natürlich schlecht, was Deine Wartezeiten angeht...)

Folgende Vorschläge hätte ich so generell zu Deinem VI:
- Da Du eigentlich 6 mal dasselbe hast, würde ich mir überlegen, die Ein- und Ausgaben in ein Array zu packen. Damit kannst Du in einer For-Schleife autoindiziert einfach alle Häuser abarbeiten, sparst Dir Platz im BD und Schleifen. Änderungen musst Du nur an einer Stelle machen, macht's Debugging deutlich einfacher.
- Generell könnte man eine Programmstruktur überlegen, die sich an einer SPS orientiert: Einlesen aller Eingänge, Verarbeiten, Ausgabe. Da der FPGA für diese boolschen Operationen deutlich schneller als Nutzer und Temperatur ist, sollte man damit deutlich einfacher programmieren können.
- FPGAs sind m.E. nicht so die richtigen Targets für User-Interaktion, Temperaturregelung m.E. auch nicht wirklcih zeitkritisch durch die großen Zeitkonstanten. Daher vielleicht mal überlegen, ob eine andere hardware-Basis das ganze nicht einfacher macht (Rechner mit Event-Struktur, State-Machine etc.)

Grüße,

ch

Hallo,

Wenn es der FPGA sein muss:
- ich würde die "Häuser" zusammenfassen, der FPGA kann bequem mit INTs rechnen und auf Byte-Ports der DO-Karte schreiben ("DO0-7" z.B.).

Ansonsten:
Mach doch das Ganze direkt auf dem cRIO. Das ist mehr als schnell genug für Temperaturregelung - und deutlich einfacher zu debuggen...

@chrissyPu:

Hi!

> Du fängst viele unsinnige Nutzereingaben merkwürdig ab (z.B. in den einzelnen Haus-Schleifen)
Nein. Die Fenster können von verschiedenen Stellen aus gesteuert werden. Z.B. von den zentralen Tastern und vom Regler. Deshalb muß ich eine gleichzeitige Ansteuerung von "Auf" und "Zu" unbedingt vermeiden!

> Warum hast Du eigentlich Waits in Deinen Schleifen? ... (BTW: Wie bedienst du das ganze? Wenn du direkt das FP des FPGA bedienst und nicht über das RT-Target ist die Performanz natürlich schlecht, was Deine Wartezeiten angeht...)
Der FPGA wird mittels frontpanel communication durch das RT-VI gesteuert, wo z.B. die Regler laufen. Ohne die Waits geht dar garnichts (race conditions)! Und das Problem existiert auch allein auf der Ebene "DigIn -> FPGA -> DigOut"!

> Da Du eigentlich 6 mal dasselbe hast, würde ich mir überlegen, die Ein- und Ausgaben in ein Array zu packen.
Das wäre zu komplex. Ich habe eine ganze Menge Kram pro Haus programmiert, da werden insges. 6 cRIO-Module bedient, und ich müßte dann irgendwie die Kanäle der I/O-Nodes in den Schleifen umschalten (weiß garnicht, ob das geht). Außerdem hätte ich durch die Schleife keine Parallelität mehr, und da gibt es auch ein paar noch zeitkritische Operationen, wie z.B. das Erfassen von schnellen Inkrementalgebern.

- Generell könnte man eine Programmstruktur überlegen, die sich an einer SPS orientiert: Einlesen aller Eingänge, Verarbeiten, Ausgabe. Da der FPGA für diese boolschen Operationen deutlich schneller als Nutzer und Temperatur ist, sollte man damit deutlich einfacher programmieren können.
Verstehe ich nicht!? Genau das passiert hier doch.

- FPGAs sind m.E. nicht so die richtigen Targets für User-Interaktion, Temperaturregelung m.E. auch nicht wirklcih zeitkritisch durch die großen Zeitkonstanten. Daher vielleicht mal überlegen, ob eine andere hardware-Basis das ganze nicht einfacher macht (Rechner mit Event-Struktur, State-Machine etc.)
Nein - die Hardware hat in diesem Projekt schon ihre Berechtigung. Der FPGA arbeitet ohne sichtbares Frontpanel "unter" dem RT-VI. Die Temperaturregelung ist hier wahrlich der langsamste Vorgang, der sicher keinen FPGA benötigt. Aber wie gesagt, das hier ist nur ein kleiner Ausschnitt des Projekts!

Du meinst, das Problem könnte in den lokalen Variablen liegen? Ich könnte natürlich mal mit globalen Variablen testen, wobei mir das irgendwie nicht logisch erscheint - das heißt aber nix

Grüße,
Roland

---

@GerdW:

Hallo,

> Wenn es der FPGA sein muss: - ich würde die "Häuser" zusammenfassen, der FPGA kann bequem mit INTs rechnen und auf Byte-Ports der DO-Karte schreiben ("DO0-7" z.B.).
Ja, muß (siehe oben). Aber abgesehen davon, ob ich jetzt Bits oder Bytes zwischen den Schleifen kommuniziere - wo liegt das Problem?

> Ansonsten: Mach doch das Ganze direkt auf dem cRIO.
Meinst Du RT? Ich brauche beides, RT+FPGA.

Ich frage mich halt, wo es im FPGA eine Verzögerung gibt. Ob's an den Variablen liegt, muß ich mal testen. Leider steht das cRIO nicht auf meinem Schreibtisch...

Grüße
Roland

Das du das Problem schon so weit runtergebrochen hast ist schon mehr als die Hälfte.. jetzt "nur noch" den Fehler lokalisieren.
Passiert beim Debuggen (Execute on Computer) das gleiche Problem?
Sind die Schleifen konstant phasenverschoben?
Vielleicht bringt es wass mal zu probieren die IO in einer Schleife zu bündeln. Also alle DIO-Operationen in der Regelschleife zusammenfassen und z.B. gemeinsam die DO umschalten.

Gruß

Hallo,

ehrlich gesagt, ich habe es immer nur auf dem FPGA getestet (ok, dafür braucht man Zeit ). Die Verschiebung ist nicht konstant, also mal reagiert das eine, mal das andere Fenster eher. Ich habe das VI jetzt mal für die beiden betroffenen Bits von lokalen Variablen auf ein Memory umgestellt. Kompiliert gerade... Ich weiß nur nicht, ob ich diese Woche noch zum Testen komme - das System steht woanders (und noch ohne Internetanbindung ).

>Vielleicht bringt es wass mal zu probieren die IO in einer Schleife zu bündeln. Also alle DIO-Operationen in der Regelschleife zusammenfassen und z.B. gemeinsam die DO umschalten.

Naja, es handelt sich ja hierbei nur um zwei Bits, die jeweils sechsfach ausgelesen werden. Die Verzögerung dürfte im ungünstigsten Fall eigentlich nur 20ms betragen (10ms pro Schleife).
Ich werde berichten, ob das Memory besser funktioniert als die lokalen Variablen.

Grüße
Roland

Anzeige

Schade, mit Memory statt lok. Variablen ist es kein Unterschied.

Tag!

(11.07.2012 12:03 )Harry Hirsch schrieb:  > Du fängst viele unsinnige Nutzereingaben merkwürdig ab (z.B. in den einzelnen Haus-Schleifen)
Nein. Die Fenster können von verschiedenen Stellen aus gesteuert werden. Z.B. von den zentralen Tastern und vom Regler. Deshalb muß ich eine gleichzeitige Ansteuerung von "Auf" und "Zu" unbedingt vermeiden!

Ja, das kann ich verstehen, ich finde die logischen Verschaltungen in der Form da aber eher ungewöhnlich für. Du liest teilweise in der gleichen Schleife aus zwei Controls. Wenn du die beide von extern setzt, kann es passieren, dass das eine Control schon gesetzt ist, das andere noch nicht, der FPGA aber schon los läuft und damit schonmal die erste Iteration durch die Schleife unsinnig durchläuft. Hatte das auch mal, hab ich dann durch eine dritte Control gelöst, die vom Host als letztes gesetzt wurde, eine Case-Struktur auslöst, in der dann die beiden relevanten Steuerdaten enthalten sind - die sind dann definitiv schon geschrieben.

(11.07.2012 12:03 )Harry Hirsch schrieb:  > Warum hast Du eigentlich Waits in Deinen Schleifen? ... (BTW: Wie bedienst du das ganze? Wenn du direkt das FP des FPGA bedienst und nicht über das RT-Target ist die Performanz natürlich schlecht, was Deine Wartezeiten angeht...)
Der FPGA wird mittels frontpanel communication durch das RT-VI gesteuert, wo z.B. die Regler laufen. Ohne die Waits geht dar garnichts (race conditions)! Und das Problem existiert auch allein auf der Ebene "DigIn -> FPGA -> DigOut"!

Naja, Race Conditions sind m.E. vor allem deswegen schlecht, weil sie geteilte Ressourcen überproportional auslasten. Auf dem FPGA gibt es aber zur Laufzeit keine geteilten Ressourcen, daher sehe ich das da nicht so kritisch und packe zumindest bei meinen Sachen nur dann Timing auf den FPGA, wenn ich's brauche.

(11.07.2012 12:03 )Harry Hirsch schrieb:  > Da Du eigentlich 6 mal dasselbe hast, würde ich mir überlegen, die Ein- und Ausgaben in ein Array zu packen.
Das wäre zu komplex. Ich habe eine ganze Menge Kram pro Haus programmiert, da werden insges. 6 cRIO-Module bedient, und ich müßte dann irgendwie die Kanäle der I/O-Nodes in den Schleifen umschalten (weiß garnicht, ob das geht). Außerdem hätte ich durch die Schleife keine Parallelität mehr, und da gibt es auch ein paar noch zeitkritische Operationen, wie z.B. das Erfassen von schnellen Inkrementalgebern.

Die Inkrementalgeber waren mir bis zu diesem Post neu, ansonsten find ich die Idee (oder die Ausführung als Integer wie oben vorgeschlagen) immer noch gut. Das schreiben der Ports halt erst nach der Verarbeitung in der Schleife, alle parallel...

(11.07.2012 12:03 )Harry Hirsch schrieb:  Du meinst, das Problem könnte in den lokalen Variablen liegen? Ich könnte natürlich mal mit globalen Variablen testen, wobei mir das irgendwie nicht logisch erscheint - das heißt aber nix

schnelle Suche: ftp://ftp.ni.com/pub/branches/germany/vi..._fpga.pdf, Folie 34. Hab ich aber auch schon an anderer Stelle gelesen.

Grüße,

ch

Moin!!!

> Ja, das kann ich verstehen, ich finde die logischen Verschaltungen in der Form da aber eher ungewöhnlich für. Du liest teilweise in der gleichen Schleife aus zwei Controls. Wenn du die beide von extern setzt, kann es passieren, dass das eine Control schon gesetzt ist, das andere noch nicht, der FPGA aber schon los läuft und damit schonmal die erste Iteration durch die Schleife unsinnig durchläuft. Hatte das auch mal, hab ich dann durch eine dritte Control gelöst, die vom Host als letztes gesetzt wurde, eine Case-Struktur auslöst, in der dann die beiden relevanten Steuerdaten enthalten sind - die sind dann definitiv schon geschrieben.

Naja, ich frage hier Nutzereingaben und Regelbefehle ab, die kommen ungetimed und "wirr", da kann ich kein "gültig!"-Flag setzen. Ich denke, ich habe sie durch die Logik entsprechend "entkoppelt".

> Naja, Race Conditions sind m.E. vor allem deswegen schlecht, weil sie geteilte Ressourcen überproportional auslasten. Auf dem FPGA gibt es aber zur Laufzeit keine geteilten Ressourcen, daher sehe ich das da nicht so kritisch und packe zumindest bei meinen Sachen nur dann Timing auf den FPGA, wenn ich's brauche.

Brauche ich! Ohne die Waits habe ich _keine_ Kommunikation mit dem RT-VI!

> Die Inkrementalgeber waren mir bis zu diesem Post neu, ansonsten find ich die Idee (oder die Ausführung als Integer wie oben vorgeschlagen) immer noch gut. Das schreiben der Ports halt erst nach der Verarbeitung in der Schleife, alle parallel...

Wie gesagt, das gibt es noch viel anderes, das würde den Thread hier unnötig aufblähen. Wenn ich das auch noch in Schleifen "komprimiere", wird's echt unübersichtlich. Ich kann da leider auch nicht die Indizes linear erhöhen, dann bräuchte ich Lookups, und... nee, laß mal. Außerdem läuft es ja schon!

> schnelle Suche: ftp://ftp.ni.com/pub/branches/germany/vi..._fpga.pdf, Folie 34. Hab ich aber auch schon an anderer Stelle gelesen.

Klappt nicht - aber Google hilft! Naja, wenn es um die Frontpanelelemente geht, Memories haben auch keine, und die sind hier genauso lahm. Ich erzeuge jetzt mal minimales FPGA-Test-VI, und dann wird getestet, was das Zeug hält...

Vielen Dank bis hierhin,

Grüße,
Roland.

So, das Minimal-VI klappt, ohne Zeitverzug, wie gewünscht. Egal, ob Variable oder Memory. Also muß ich das dicke VI schrittweise runterstrippen, um zu sehen, was bremst. Entweder, es sind in der Summe zu viele Frontpanelelemente, oder vielleicht sind es die Abfragen der Analogausgänge, oder... Ich denke übrigens, daß der Unterschied zwischen lokalen und globalen Variablen eher im Platzverbrauch liegt, nicht in der Geschwindigkeit.
Aber jetzt ist erst mal Wochenende.

Grüße
Roland