Case Struktur 2 Schleifendurchläufe verzögert True setzen aber sofort auf False

Hallo zusammen,

ich suche schon wieder eine Lösung und ich komme nicht drauf.

Ich bekomme Messwerte als Eingang die ersten 2 Messwerte schlagen hierbei extrem aus was wohl an dem Anlauf des Systems liegt. Prinzipiell ist es kein Problem, da die ersten 5 Werte nicht verwendet werden, aber da die Messwerte geplottet werden, sieht das extrem komisch aus wenn die ersten 2 Werte einfach 30-40 % über dem Rest liegen sieht aus wie ein Schornstein.

Meine Vorhaben wäre jetzt einfach, die ersten 2 Messwerte einfach auf Null korrigieren und dann sieht der Plot auch ordentlich aus.

Mir fehlt jetzt aber für meine Planung eine Verzögerung die nur verzögert wenn von false auf true gesetzt wird aber nicht von true auf false.
Ein VI für labview 14 habe ich angehängt.

Hat jemand eine Idee wie ich das bewerkstelligen kann?

Gruß Bachatero18

  Test.vi (Größe: 5,93 KB / Downloads: 213)

Hi Bachatero18,

hast du nicht mal etwas schwierigeres? :-)

Vielleicht sollte dich mal irgend jemand vor ein LabVIEW FPGA Projekt setzten, aber nicht den quatsch mit "LabVIEW as usual on FPGA", sondern SCTL(Single-Cycle Timed Loop) ...

Ich beschreibe es per Text, damit es nicht ganz so einfach ist :-)
(ein Bildchen oder VI kann ich immer noch nachreichen)

Schalte in die boolsche Leitung zwei Feedback nodes hintereinander (aus optischen Gründen die Richtung von links nach rechts ändern), dannach folgt ein logisches UND mit der boolschen Leitung aus dem Vergleich (Eingangmesswert > 1.0).

Alternative mit Shift Register:
Shift Register erstellen. Vergleichsergebnis rechts ins Shift Register stopfen, links das Shift Register erweitern. Nicht vergessen links die nun vorhandenen beiden Eingänge des Shift-Registers mit Defaultwerten (False) zu verbinden. Und nun den unteren Ausgang des Shift Registers so wie oben mit logisch UND mit dem Ergebnis des Vergleichs verbinden.
(ähm ... ob das jetzt verständlich ist ...)

Nachtrag:

Welche von beiden Varianten du wählst ist fast ein wenig Geschmackssache. Ist das Diagramm in der While Schleife schon etwas unübersichtlicher und wenn du es nachträglich irgendwo einfügen musst, dann ist wahrscheinlich die Lösung über die Feedback-Node besser geeignet. Im vorliegenden Fall mit dem sehr einfachen Diagram würde ich das Shift-Register bevorzugen, weil damit nur noch das UND innerhalb der While-Schleife im Diagram steht und hier kompakter und IMHO auch übersichtlicher ist.

   

Moin Martin,

das kann doch nicht wieder so einfach sein .
Ich brauch Wochenende .

Also bis dato nicht, das einzige ist, dass das Programm bei verschiedenen Bildschirmauflösungen verwendet werden soll.
Die automatische Skalierung funktioniert nur bedient und das sieht nicht aus werde wohl für jede Bildschirmauflösung das Frontpanel anpassen und dann ist gut.

(07.11.2020 12:48 )bachatero18 schrieb:  Also bis dato nicht, das einzige ist, dass das Programm bei verschiedenen Bildschirmauflösungen verwendet werden soll.
Die automatische Skalierung funktioniert nur bedient und das sieht nicht aus werde wohl für jede Bildschirmauflösung das Frontpanel anpassen und dann ist gut.

Ich emfinde diese automatische Skalierung zwar auch als reichlich misslungen und eher als Katatrophe, aber in manchen Fällen funktioniert es dann doch ausreichend gut. Der Benutzer sollte nicht ständig die Fenstergröße ändern. Die Unterschiede der Bildschirmauflösungen sollten (je nach Fall) nicht zu rießig sein. Entwickelt wird das Ganze für die kleinste Bildschirmauflösung. Die Elemente auf dem FP (Front Panel) sollten ganz exakt zueinander ausgerichtet sein (auf's Pixel genau). Cluster oder Arrays sollten auf dem FP möglichst nicht vorhanden sein. Manchmal hilft auch das Gruppieren von Elementen. gelegentlich ist es sinnvoll eine Art "Reset" einzubauen. Damit meine ich, dass bei Einstellung auf die kleinste Auflösung alle Elemente alle wieder auf die ursprünglichen Positionen und Größen zurückgesetzt werdem. Das geht recht einfach (Abfrage von Position und Größe aller Elemente auf dem FP beim Programmstart und beim "Reset" werden die dann alle wieder eingestellt. Das korrigiert die Rundungsfehler welche durch die Skalierung entstehen.

Bei dieser automatischen Skalierung bestehen zwei wesentliche Probleme: Die Umrechnung erfolgt nur auf ganze Zahlen und die Umrechnung erfolgt immer nur ausgehend von der aktuellen Position und Größe der Elemente. Dadurch ergeben sich ständig Rundungsfehler die sehr schnell immer größer werden. Das müsste eigentlich anders funktionieren. Die Skalierung müsste immer ausgehend von der ursprünglichen FP-Größe erfolgen (also von den Positionen und Größen die der Entwickler festgelegt hat).

Dazu gibt es dann noch die Problematik mit den Schriftgrößen. Das ist jedoch etwas ganz anderes und hängt doch sehr von der jeweiligen Anwendung ab. Alle Schriftgrößen einfach immer zu skalieren ist genauso falsch, wie alle Schriftgrößen so zu belassen wie sie sind. Da bleibt nichts anderes, als es individuell für jedes Element festzulegen.

Ok, das kann so implementiert werden und dann funktioniert es auch. Warum NI das so gemacht hat, wie es jetzt ist, das were ich wohl nie wirklich verstehen ...