Hashtable in Labview

Hallo liebe LVFler,

ich bin mal wieder hier. Und bin entweder grade dumm oder die Funktion gibts wirklich nicht.

Ich suche eine Möglichkeit in der Art einer Hashtable effizient auf Daten zugreifen zu können. Sprich: Ich will anhand eines Schlüsselworts direkt aus einen Datensatz effizient zugreifen können. Dabei sind die Schlüsselwörter erst zur Laufzeit bekannt.

Ich hab sowas bisher immer über eine einfache Suche (Array durchlaufen und vergleichen) realisiert, aber das ist ja nun wahrlich keine performante Lösung. Gibts sowas schon in Labview? Ich nehme an durch Zeitdruck im Projekt kann ich sowas derzeit selbst wenn ich ne Idee hätte noch nicht bauen - auch wenn sichs wahrscheinlich zur Not auch einfach später performant machen lässt.

Für alle die wie ich ticken und nach dem Hintergrund fragen, weil Sie eventuell Alternativlösungen im Kopf haben:

1. Es wäre meine bevorzugte Lösung, da ich das als Architektur für sinnvoll halte und immer wieder in ähnlicher Form bisher gebraucht hätte.
2. Konkret geht es darum eine Steuerung für eine Anlage aufzubauen, die über eine INI konfiguriert wird. Dabei sollen Elemente und Parameter über Schlüsselwörter angesprochen werden (ja ich weiß, wenn der Nutzer mist baut und die Schlüsselwörter nicht unique bleiben habe ich ggf. ein Problem bzw. muss das als Fehler abfangen). Das heist dann auch, dass ich im Programm ebenfalls mit den entsprechenden Schlüsselwörtern arbeiten muss wenn ich die Elemente anspreche und daher immer wieder anhand eines Schlüsselworts mir von einem "Verwaltungsobjekt" das richtige Objekt raussuchen lassen mit dem ich grade reden will.


Vielen Dank schonmal im vorhinein und Grüße.

P.S: Ja ich nutze LVOOP und es war hier und da sogar nützlich, auch wenn man häufig merkt das es von NI nicht konsequent umgesetzt wurde.

Wir nutzen dafür Varianattribute. Der Wert eines Attributes kann ein beliebiger Datentyp oder Referenz sein. Mit ein paar HilfsVI kann man damit elegante Lösungen bauen.

(08.11.2021 13:12 )Kiesch schrieb:  P.S: Ja ich nutze LVOOP und es war hier und da sogar nützlich, auch wenn man häufig merkt das es von NI nicht konsequent umgesetzt wurde.

Als OOP benutzen wir das G# Framework.

Hi th13,

danke für die Info. Variants finde ich persönlich begrenzt praktisch. Quasiobjekte die die Komplikationen von Objekten mitbringen aber noch nicht alle Vorteile von Objekten haben.

Da ist das G# Toolkit wahrscheinlich interessanter. Muss ich mir bei Gelegenheit mal anschauen. Danke für den Tip. Kommt allerdings als Lösung für das aktuelle Projekt aus Zeitgründen wahrscheinlich nicht in betrachtet, da ich nicht abschätzen kann wie ich den ganzen restlichen Code dafür ggf. umarbeiten muss. Was ganz neues probieren ist selten ne gute Idee wenn die Deadline in nem Monat ist.


Was ich auch schon gesehen habe ist, dass LV 2020 (?) scheinbar ein "Search 1D Array (sorted)" hat, das ich für meine Zwecke im Prinzip gebrauchen könnte um damit einfach eine performante Lösung zu bauen. Allerdings soll das Projekt (derzeit) in geschrieben werden und die höchste Version die ich dafür nutzen kann ist (selbst wenn die Uni doch noch endlich mal eine neue Version kaufen sollte würden mir wahrscheinlich die Codemanagement und der exe builder fehlen).

Gruß Kiesch

*edit* Mir ist grad aufgefallen, das selbst das "Search 1D Array (sorted)" baggage mitbringt. Da kann ich zwar aus einem Sortierten Array schnell indizes ermitteln und mit denen dann aus einem zweiten Array die Elemente rauspicken, muss aber dafür sorgen, dass ich bei jeglichem Sortieren beide Arrays richtig sortiere. Wobei das immerhin im wesentlichen einmal bei der Initialisierung passieren würde und daher nicht ganz so zeitkritisch ist.

(08.11.2021 13:40 )Kiesch schrieb:  Variants finde ich persönlich begrenzt praktisch.

Hm, kann ich nicht nachvollziehen. Wir haben damit eine Dictionary-Klasse gebaut, die die typischen get/set/hasEntry-Methoden hat und verschiedene Datentypten unterstützt. Und soweit ich hier im Forum und an anderen Stellen gelesen habe, sind Variantattribute meist der erste Hinweis, wenn nach Hashtabellen in LabVIEW gefragt wird. Vielleicht gibtst du Ihnen ja noch eine Chanche

Seit 2019 gibt es die Collection-Palette mit Maps, evtl. gefallen die dir besser. Dazu kann ich aber nix sagen, da wir unsere Klasse bisher nicht umgestellt haben. Daher hier zwei Threads:
• https://forums.ni.com/t5/LabVIEW/LV2019-...anguage=en
• https://lavag.org/topic/21004-labview-20...data-type/

Hallo Kiesch,

Zitat:Variants finde ich persönlich begrenzt praktisch.

Ich finde die Variant-Attribute extrem effizient und hilfreich - seit etlichen Jahren…

Ich habe damit eine komplette Messdaten-Verwaltung implementiert: innerhalb der Prüfstandssoftware habe ich so Zugriff auf aktuelle Messwerte, Messwert-Historie, (gleitende) Mittelwerte, kann auf Gruppen von Kanälen zugreifen, kann Gruppen von Kanälen oder alle loggen, … - und das alles über den Namen der einzelnen Messkanäle.
(Ein anderes Variant speichert dazu noch die Konfigurationen der ganzen Kanäle in seinen Attributen.)

Ab LV2019 kannst du dann eben Maps statt der Variantattribute verwenden.

Ich kann meinen Vorschreibern nur zustimmen.

Hashtable bis LabVIEW 2018 -> Variant-Attribute. Die Suche nach Einträgen ist extrem effektiv.
Ab LabVIEW 2019 ist das deutlich einfacher umsetzbar mit Maps. Genauso effizient, und was ich persönlich gut finde, beim Key bist du nicht mehr auf den Datentyp "String" beschränkt.

Gruß, Jens

Anzeige

Das sieht sehr interessant aus, bisher suche ich mit "search 1D Array"
   
Was bei ca 140 Werten wohl keine Auswirkung hat, dennoch sieht die Variant-Methode sehr praktisch aus, hat ein bischen gebraucht, bis ich es verstanden habe (habe eigentlich nie mit Variant-Attributen gearbeitet), ausschlaggebend war dieser Beitrag, Codebeispiele sind halt die besten, vielleicht hilft dir der Beitrag auch Kiesch.
Das lässt sich sicher auch gut aus ini Dateien befüllen.

MfG Timo

Mea Culpa, man lernt nie aus. Ich hätte erst nochmal in den Link von th13 schauen sollen bevor ich Variants ausschließe.

Die Bottom Line ist also: Nen Variant kann ich mehr oder weniger zur Laufzeit erzeugen (und zwar die Datenstruktur selbst), so dass ich nicht mit nem Array von Variants Ende sondern am Ende nen Variant habe den ich nur nach Attributen Fragen muss (meine Werte). Da kann ich mir denke ich ne Klasse drumrum stricken die für mich die Verwaltungsarbeit erledigt, auch wenn ich dafür noch das Konzept begreifen muss das genutzt wird. *ergo: Lesen und verstehen und begreifen*

Mal kucken ob ich das anhand der verlinkten Infos schnell schaffe. Danke an alle. Lerneffekt: Variants haben eventuell doch einen sinnvollen Use Case für mich.

Gruß Kiesch

P.S: Ich hatte deswegen auch geschrieben, dass ich Variants für mich persönlich bisher nutzlos gefunden habe, da mir der Mehrwert gegenüber LVOOP-Objekten nicht klar war.

P.P.S: Sind die casts sehr zeitaufwändig? (Variantattribut nach original Datentyp)

P.P.P.S: Danke auch für die Beispiele. Hab jetzt vielleicht bisschen großzügig Lösungen markiert, aber grade die verlinkten Beispiele helfen mir hoffentlich das zu verstehen und umsetzen zu können.

Du hast auch lv2019 in deiner Liste stehen, übersehe jg's post nicht:

(08.11.2021 21:19 )jg schrieb:  Ab LabVIEW 2019 ist das deutlich einfacher umsetzbar mit Maps. Genauso effizient, und was ich persönlich gut finde, beim Key bist du nicht mehr auf den Datentyp "String" beschränkt.

(09.11.2021 10:50 )Kiesch schrieb:  P.P.S: Sind die casts sehr zeitaufwändig? (Variantattribut nach original Datentyp)

So ganz generell kostet die Umwandlung der Variants schon deutlich messbare Zeit. Zumindest bei den Attributen hält sich so sehr in Grenzen, dass du in LabVIEW kaum eine schnellere Lösung finden wirst.

Übrigens: Wenn du bei "Get Variant Attribute" die Eingänge "key" und "default value" nicht verbindest, dann bekommst du alle enthaltenen Attribute.