Clusterarrays synchronisieren

Hallo LVF!

Habe nun meine nächste Optimierfrage. Ich habe ein Clusterarray, das zuerst nach Node-Nummer sortiert werden muss. Es sind derzeit nur zwei unterschiedliche Knotennummern. Danach muss ich aus den zwei Clusterarrays nur eins machen. Die Counter von beiden Arrays werden verglichen und wenn diese übereinstimmen werden die zwei Pakete zu einem zusammengefügt.

Wie würdet ihr das machen?

Moin eg!

Sage mal sind die Count Werte dir unbekannt oder sind das feste Größen, also gibt es nur bestimmte Counts?

Schöne Grüße
Falk

Nö, Counter sind unbekannt. Die Pakete müssen also dann zusammengesetzt werden, wenn der Counter eines Paketes und der Counter des anderen Paketes übereinstimmen.

OK, eine Frage habe ich auch noch. Weiß man denn, ob von beiden Nodes immer ein Paket mit Count X kommt, oder kann es auch vorkommen, dass es beispielweise nur Node A vorhanden ist?

Es ist alles variabel. Es ist unbekannt wieviele Pakete von welchen Knoten mit welchem Counter vorhanden sind.
Im besten Fall soll es pro Knoten gleiche Anzahl der Pakete mit gleichem Conter vorhanden sein. Leider können bei der Aufzeichnung in die Datei die Counter auseinanderlaufen (weil diese unterschiedliche µCs haben und damit unterschiedliche Taktzeiten) und es kann auch passieren dass ein Knoten ausfällt. Also im Worst Case kommt am Ausgang des VIs ein leeres Array raus.

So, im Anhang mal ein Vorschlag meinerseits. Wie bei dir derzeit begrenzt auf 2 Nodes.

Will man auch noch diesen Parameter variable gestalten, so muss man sich eine andere Datenstruktur für Ergebnis-Array überlegen. Erster Gedanke war halt einfach einen 2 dim Array nehmen, wo die Spalte den Counts und die Zeilen einfach den Nodes entspricht. Das wäre nur dann sinvoll, wenn halt sicher wäre, dass von jedem Node auch immer ein Paket mit Count X kommt. Wenn das nicht der fall ist, so ist entspricht ja bekanntlich die Zeilenanzahl stets der der längesten Spalte. Und wenn bei einer Spalte nur 1 Wert drin steht wird der Rest eben mit lauter Nullen aufgefüllt. Außerdem weiß man dann nicht mehr, welche Info von welchem Node kommt. Somit muss man sich was überlegen, aber auch dafür würde sich eine Lösung finden.


Schöne Grüße
Falk

Anzeige

Danke Falk.

Ich lade einfach meine zwei VIs und die Datei hier hoch. Das andere ist in diesem Thema schon besprochen worden.

Falls jemand Interesse hat kann es ausprobieren. Ich habe schon aufs Usertreffen (muss Morgen früh aufstehen) umgeschaltet und will erst am Montag damit weitermachen.

@Falk, könntest du bitte deinen Vorschlag kommentieren?

Gruß, eg

P.S. im Anhang sind zwei VIs, zwei Controls und die Datei. Starten bitte GSM_Parse_File.vi und die beigelegte Datei auswählen.

Hallo eg!

Habe eben nochmal fix einen Blick in deine VIs geworfen und diese auch mal laufen lassen. Dabei musste ich feststellen, dass ich wohl nicht alles von deiner Grundidee verstanden habe. Um nochmal sicher zu gehen frage ich lieber nochmal nach.

Wenn ich mir dein Sortierungs-VI anschauen, so zeigt es sich, dass du dort auch eine Filter-Funktion implementiert hast, oder? Zuerst sortierst du die Daten nach den Nodes. In der letzten Schleife lässt du dann alle Werte von Node 162 durchlaufen, nimmst den Count-Wert davon und durchsucht den vorher erstellten Count-Array von Node 161. Findest du dort keinen gleiche Count-Wert so wirfst du auch die Information von Node 162 weg bzw. nimmst sie nicht in deinen Array auf.

Dieser wichtige Punkt ist mir bisher entgangen, was natürlich in meinem oberen Beispiel nicht berücksichtigt wird. Auch gibt es dort keine strikte Trennung ob F1 - F2 und T1 - T2 mit den Werten von Node 161 oder 162 gefüllt werden. Letzteres könnte man zwar ohne Probleme mittels einer kleinen Case-Struktur lösen, aber damit wäre die Filterung noch nicht aus der Welt. Nun ja mein Ansatz war vielleicht ein Schnellschuß, der sich mit deinen Anforderungen doch nicht so gut deckt.

Einen Verbesserungsvorschlag hätte ich trotzdem. Du baust dir in deiner zweiten Schleife deines Sortierung-VIs ja mal fix einen Array mit den Count-Werte von Node 161 zusammen. Warum machst du das nicht gleich in der ersten Schleife mit?

Ok, werde mich mal langsam ins Bett werfen. Wünsche allen eine angenehme Nachtruhe.

Schöne Grüße
Falk

Moin!

Irgendwie hat mich die Problemstellung nicht losgelassen, so dass ich nochmal meinen Lösungsansatz überarbeitet habe.

Im Anhang also mein Vorschlag unter Berücksichtigung der im vorhergehenden Beitrag diskutierten Bedingungen. Zu mindestens ein erster Vergleich deines Programms und meinen Vorschlag zeigte gleiche Ergebnisse.
Auch habe ich auf die ganze Geschichte hinsichtlich der Leistungssteigerung durch " Teilarray ersetzen" statt am "Array anhängen" verzichtet. Hintergrund ist zum einen der, dass ich mir darüber auch nochmal ein generelles Konzept überlegen möchte und zweitens wohl das Lesen der Datei die Bremse darstellt.

Schöne Grüße
Falk

' schrieb:Ich lade einfach meine zwei VIs und die Datei hier hoch.

Habe sie mir mal angesehen und Anderungen vorgenommen. Wunder sind allerdings nicht dabei herausgekommen, die meiste Zeit dauert das kleckerweise Einlesen, alles andere dauert deutlich weniger.
Die gmessene Zeitdauer für das VI ist bei mir 8.5 sek. 2 sek konnte ich noch herausholen d.h. es dauert dann 6.5 sec. An den Verbesserungen sind zu je 1 sek diese beiden Änderungen beteiligt:[list]
[*]Umstellung auf Array ersetzen wie besprochen. Die Größe der Initialisierung spielt praktisch kein Rolle, also man braucht vor einem genügend hohem Wert nicht zurückzuschrecken.<>
[*]Beim Einlesen werden die beiden U16-Werte hinterereinander als ein U32-Wert gelesen, es wird dann weniger oft gelesen und die ganze Struktur vereinfacht sich. Es gib nur noch eine Casestruktur mit den 3 Cases x7E7E0002, x7E7E0003, Voreinstellung.<>
[st]Die weiteren Änderungen bringen praktisch nichts, die habe ich nur gemacht, weil ich nicht zusehen kann, wenn die Polymorphie von FFT.vi und ZahlNachString.vi nicht wahrgenommen wird und diese VIs überflüssigerweise in for-Schleifen eingewickelt werden.
   
Nur Main-Vi, sonst nichts geändet
  GSM_Parse_FileWA2.vi (Größe: 50,2 KB / Downloads: 215)