Algorithmus in Labview umsetzen, brauche Rat!

Hallo,
ich bin gerade dabei ein Algorithmus in Labview umzusetzen bin jedoch ein bisschen überfordert und komme auf kein grünen Zweig.
Vielleicht ist ein erfahrener Labviewer/Programmierer hier im Forum, der mir eventuell ein Tipp geben kann.
Es geht hier um das Auffinden der bestmöglichen Positionen eines Mikrofonsensorarray in einem Koordinatensystem (x,y,z).
Schwierigkeiten habe ich besonders mit den folgenden Punkten:

10. Setze Index m auf 0;
11. Verschiebe die Position in positiver X Richtung um schrittweise s (z.b 1).
12. berechne die neue Summe der Fehlerquadrate (wird vorher im Algorithmus erklärt)
13. wiederhole schritt 11 und 12 solange bis die Summe der Fehlerquadrate nicht mehr kleiner wird (wenn sich bereits bei der ersten
Verschiebung in X-Richtung eine Verschlechterung der Summe der Fehlerquadrate ergibt muss die Schrittweite s in negativer X Richtung verschoben werden.
14. Führe Schritte 11 bis 13 für den Y Vektor aus
15. Führe Schritte 11 bis 13 für den Z Vektor aus
16. erhöhe m um 1
17. wiederhole Schritte 11 bis 16 bis m=N-1

mein Problem ist, dass die Eingangswerte den Ausgangswerten entsprechen.
Ich weiß auch warum nur kann ich grad keine Lösung dafür finden auch wenn es noch so trivial ist:
In der Schleife wird nach dem kleinsten Fehlerquadrat gesucht,
bis das kleinste Fehlerquadrat gefunden ist. Bei jedem Durchgang wird überprüft, ob das berechnete Fehlerquadrat größer ist als das vorherige,
wenn das nicht der Fall wird die Schrittweite s inkrementiert und es findet eine neue Berechnung statt. Wenn das berechnete Fehlerquadrat kleiner ist als das vorherige wird in die andere Schleife gegangen
und für die andere Richtung geschaut. Zuerst wird dekrementiert und dann wieder überprüft. Dabei entsteht ein Nulleffekt. Um das verständlich zu machen hier mal kurz ein Beispiel was passiert:

Durchgang 0:
Schrittweite s wird inkrementiert
Fehlerquadrat vorher: 1000
berechnetes Fehlerquadrat : 100
100>1000 = False


Durchgang 1:
Schrittweite s wird inkrementiert (Durchgang 0 ist False deswegen wird erneut für den neuen inkrementierten X wert eine Berechnung durchgeführt)
Fehlerquadrat vorher: 100
berechnetes Fehlerquadrat : 200
200>100 = True

Zwischendurchgang -> geht in die Schleife für andere Richtung, weil Durchgang 1 True ist
Durchgang 0:
Schrittweite s wird dekrementiert
Fehlerquadrat vorher: 200
berechnetes Fehlerquadrat : 100
100>=200 = False

Durchgang 1:
Schrittweite s wird dekrementiert und somit wieder da wo es vorher war
Fehlerquadrat vorher: 100
berechnetes Fehlerquadrat : 200
200>=100 = True

somit bleibt x wie es ist, wobei ich die Schrittweite bräuchte wo x tatsächlich am kleinsten ist.
Falls euch sonst noch was auffällt was mich danach in Schwierigkeiten bringen könnte bitte erwähnen.
Im Anhang noch ein Bild vom Algorithmus Schritte 1-17 wobei 1-9 eigentlich selbsterklärend sind und nicht
weiter notwendig sind zu erklären für mein Problem.

Anzeige

Hallo,

Ich habe mir kurz mal das VI angesehen doch leider ist es sehr schwierig durch diese ganzen Drähte den Überblick zu behalten. Deshalb mal ein kleiner Tipp aus eigener Erfahrung, ohne konkret auf dein Problem einzugehen:

Versuche Codeabschnitte die wiederverwendet werden in einem SubVI zusammenzufassen (z.Bsp. (Mx-Sx)^2; (My-Sy)^2;...) das spart ne Menge Platz auf dem Blockdiagramm und erleichtert ungemein die Lesbarkeit. Des Weitern würde ich versuchen keine Drähte zu Kreuzen, ich denke die wenigsten hier haben Lust einem Draht zu folgen der gefühlte 3km weiter irgendwo angeschlossen ist (Drähte können auch Beschriftet werden). Kein Blockdiagramm sollte breiter als dein Bildschirm sein.
Falls du dich intensiver mit LabVIEW befassen willst oder musst, kann ich dir "The LabVIEW Style Book" ans Herz legen. Fand ich zumindest sehr hilfreich.

Gruß
Stefan

Nachtrag:
Wenn du dir die entsprechenden Sub-VIs erstellt hast, was sicher ratsam wäre, achte darauf, diese auf ablaufinvariant zu setzen. Sonst wird nämlich alles, was jetzt schön parallel läuft, seriell ablaufen.

Außerdem wäre ich vorsichtig mit eindimensionalen Abbruchbedingungen in While-Schleifen. Tritt die deklarierte Bedingung durch ein von dir nicht bedachtes Eingangssignal nicht (nie) auf, wird dein Programm genau dort festhängen - da hast du dann viel Freude beim Debuggen, besonders, wenn das einmal pro Woche auftritt (eigene Erfahrung)

Gruß, Marko

okay erstmal danke für die Antworten!
habe das VI aufgeräumt und ich glaube meinen Fehler selber gefunden.
Könnte vielleicht einer vergleichen ob die Programmierung, die ich
erstellt habe dem Algorithmus entspricht oder doch noch Gedankenfehler drin sind?

Im Anhang habe ich von den verschiedenen Case Strukturen
ein Screenshot gemacht und hier mit eingefügt.

Die Screenshots sollten dem Algorithmus 10-13 und 17 entsprechen:
10. Setze Index m auf 0;
11. Verschiebe die Position in positiver X Richtung um schrittweise s (z.b 1).
12. berechne die neue Summe der Fehlerquadrate (wird vorher im Algorithmus erklärt)
13. wiederhole Schritt 11 und 12 solange bis die Summe der Fehlerquadrate nicht mehr kleiner wird (wenn sich bereits bei der ersten
Verschiebung in X-Richtung eine Verschlechterung der Summe der Fehlerquadrate ergibt muss die Schrittweite s in negativer X Richtung verschoben werden.
17. wiederhole Schritte 11 bis 16 bis m=N-1

Gruß David

Hallo David,

Anmerkungen, die sich nicht auf den Algorithmus beziehen:
- lokale Variablen durch Drähte ersetzen
- wenn du schon eine globale Variable verwendest, dann würde ich im subVI direkt abfragen
- du hast ein subVI mit 6 Inputs an der linken Kante des Icons erstellt: sieht sehr unübersichtlich aus. Besser wäre hier der Einsatz eines Clusters, der die 5 unteren 1D-Arrays in nur einem Draht zusammenfasst. Diese 5 Arrays scheinen sich ja nicht zu ändern mittendrin…
- zum aufräumen: Schieberegister sehen noch "hübscher" aus, wenn die Drähte möglichst gerade von links nach rechts verlaufen (das gilt auch sonst)
- am subVI zum Berechnen der Abweichung sieht man CoercionDots: müssen die sein und haben sie Einfluss auf das Rechenergebnis?
- Deine While-Loops stoppen nur unter einer Bedingung: was passiert, falls diese Bedingung nie eintritt?
- Wozu überhaupt While-Loops? Dein Mikrofonarray dürfte nur in einem begrenzten Raum bewegt werden, also gibt es Grenzen für XYZ. Zusammen mit deiner Schrittweite kann man deshalb doch für jede Richtung ein 1D-Array von Stützstellen definieren, die eine FOR-Loop autoindizierend abarbeitet… (Auch FOR-Loops haben eine Stop-Condition!)

Danke für die Allgemeinen Sachen,
habe die Sachen so umgesetzt, manche Sachen habe ich nicht verstanden:

Zitat:- lokale Variablen durch Drähte ersetzen

Erledigt!

Zitat:- wenn du schon eine globale Variable verwendest, dann würde ich im subVI direkt abfragen

Meinst du damit ich soll ein SubVi erstellen, indem die Funktion abgearbeitet wird?
Das Problem das ich habe ist, dass dort Zufallsvariablen erzeugt werden, die bei jedem neu Ausführen geändert werden.
Ich könnte das machen, müsste das VI allerdings nur einmal ausführen lassen und dann mit allen Stellen verdrahten, was
ziemlich unordentlich aussehen würde.

Zitat:- du hast ein subVI mit 6 Inputs an der linken Kante des Icons erstellt: sieht sehr unübersichtlich aus. Besser wäre hier der Einsatz eines Clusters, der die 5 unteren 1D-Arrays in nur einem Draht zusammenfasst. Diese 5 Arrays scheinen sich ja nicht zu ändern mittendrin…

Hab vorhin versucht das zu machen, das Problem ist das ganze war gerade nur für die X-Koordinate des Mikrofons. Es wird dort die kleinste Summe der Fehlerquadrate berechnet. Es folgt das gleiche noch für Y und Z und später auch noch für Schallquelle X, Y und Z. Müsste also die 1-D Arrays bündeln und jedes mal Aufschlüseln.

Zitat:- zum aufräumen: Schieberegister sehen noch "hübscher" aus, wenn die Drähte möglichst gerade von links nach rechts verlaufen (das gilt auch sonst)

Erledigt!

Zitat:- am subVI zum Berechnen der Abweichung sieht man CoercionDots: müssen die sein und haben sie Einfluss auf das Rechenergebnis?

Mein Fehler hab vergessen das zu ändern. Erledigt!

Zitat:- Deine While-Loops stoppen nur unter einer Bedingung: was passiert, falls diese Bedingung nie eintritt?

Naja es wird ja nach dem kleinsten Fehlerquadrat gesucht, es muss also irgendwann größer werden als das zuvor berechnete Fehlerquadrat?!

Zitat:- Wozu überhaupt While-Loops? Dein Mikrofonarray dürfte nur in einem begrenzten Raum bewegt werden, also gibt es Grenzen für XYZ. Zusammen mit deiner Schrittweite kann man deshalb doch für jede Richtung ein 1D-Array von Stützstellen definieren, die eine FOR-Loop autoindizierend abarbeitet… (Auch FOR-Loops haben eine Stop-Condition!)

Warum sollte ich While-Loops vermeiden?

Jetzt nochmal zum Algorithmus - um den geht es mir eigentlich, ich kann noch so schön alles hergerichtet haben, wenn ich Quatsch berechne
Im Anhang nochmal ein paar Bilder.
Ich versuche mal zu erklären was ich umgesetzt habe:

In eine While Schleife werden 6 1D Arrays übergeben. Die 1D Arrays enthalten
Koordinaten (von oben nach unten) der Mikrofone X,Y,Z und der Schallquelle X,Y,Z.
Das 1D Array mit der X-Koodinate des Mikrofons ist dabei ein Schieberegister.
Der Inhalt des 1D Arrays an der Stelle i wird dabei um die Schrittweite s zunächst erhöht.
Aus dem sich veränderten 1D Array und den übrigen 1D Array wird nun der neue Abstand delta s
aus Quelle und Mikrofon berechnet. Aus den realen Abstand und dem neuen berechneten Abstand wird dann
dann die Summe der Fehlerquadrate bestimmt. Es wird verglichen, ob die Summe der Fehlerquadrate
die berechnet wurden größer als die alten übergebenen Werte sind.
Falls nicht werden die Werte durchgeschleift (Case Fall: False) und das Spiel geht wieder von vorne los
(um Schrittweite s erhöhen, neuer Abstand berechnen, Summe der Fehlerquadrate, erneuter Vergleich).
Irgwann ist die Summe der berechneten Fehlerquadrate größer als der Wert davor.
Wir befinden uns jetzt im Case Fall:True dabei ist die zweite Bedingung auch True, da
die Schleife nicht im 0. Durchlauf ist. Da der While Schleife immer die neu berechnete Summe der Fehlerquadrate
übergeben wird, wird hier nochmal die Summe der Fehlerquadrate berechnet die davor aktuell war. Die Schleife ist durch,
da die Abbruchbedingung zutrifft: Summe der berechneten Fehlerquadrate ist größer als die davor berechnete Summe
der Fehlerquadrate.

Falls schon beim ersten Durchlauf die Summe der Fehlerquadrate größer ist als die übergebene Summe der Fehlerquadrate
muss wie im Algorithmus beschrieben in die andere Richtung geschaut werden.
Bedingung 1: Summe 1 ist größer als Summe 2 und wir befinden uns im Durchlauf 0.
Nun befinden wir uns in dem Case Fall True, False.
Hier muss ebenfalls ein Schieberegister definiert werden der in die andere Richtung schaut.
Abbruchbedingung ist ebenfalls der Vergleich der Summe der Fehlerquadrate. Eigentlich ist das
analog aufgebaut nur er schaut in die negative Richtung.

Fällt einem ein Gedankenfehler auf, in dem ich vom Algorithmus abweiche?
Gruß David

Anzeige

(25.09.2015 23:05 )gibsonuser schrieb:  Naja es wird ja nach dem kleinsten Fehlerquadrat gesucht, es muss also irgendwann größer werden als das zuvor berechnete Fehlerquadrat?!

...

Warum sollte ich While-Loops vermeiden?

Ich sprach ja schon von fehlerhaften Eingaben. Wenn dein vorgelagertes VI durch einen Fehler ein leeres Eingangsarray übergibt, dann sollte das ganze auch noch funktionieren. Deshalb verknüpft man in WhileLoops ein K.O.-Kriterium als Abbruchbedingung.

Und deshalb sind ForLoops ungefährlicher. Aber vielleicht musst du auch erst mal selbst ein paar Stunden nach einem hängenden VI gesucht haben, um uns zu glauben.


Gruß, Marko