LabVIEWForum.de
strike Typisierung vs variable Anschlüsse - Druckversion

+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Datenkommunikation (/Forum-Datenkommunikation)
+---- Thema: strike Typisierung vs variable Anschlüsse (/Thread-strike-Typisierung-vs-variable-Anschluesse)

Seiten: 1 2


strike Typisierung vs variable Anschlüsse - JATler - 19.10.2017 11:58

Hallo Community,

ich habe eine große Anzahl von VI's, deren Ausführung oder Nicht-Ausführung vom Nutzer zur Laufzeit in einer Art Rezept oder Plan festgelegt wird. Bei der Abarbeitung des Plans rufe ich diese VI's dynamisch mittels "Aufruf über Referenz" auf. Der "Aufruf über Referenz" verlangt eine strikte Typisierung, das bedeute für mich alle VI's müssen das gleiche Interface / die gleichen Anschlüsse haben. So weit, so gut, alles funktioniert. (siehe Anhang)

Wenn ich aber in der Zukunft einen weiteren Anschluß benötige, müßte ich alle VI's die ich bis dahin schon habe überarbeiten und wie gesagt, es sind viele. Deshalb suche ich nach einer Möglichkeit Anschlüsse hinzufügen zu können ohne die alten VI's überarbeiten zu müssen. Eine Idee war: alle Signale in einem Cluster zusammen zu fassen und nur diesen Cluster als Anschluß zu definieren, kommt später ein Signal hinzu erweitert man diesen Cluster einefach um dieses Signal --> Ergebnis: Anschluß bliebe ein Cluster, alte VI's schlüsseln weiterhin nur die bisherigen Signale auf und müssen somit nicht verändert werden, neue VI's schlüsseln zusätzlich die neuen Signale auf, somit könnte dieses Interface "wachsen" und bliebe dennoch rückwärtskompatibel. Geht aber nicht, Cluster ist eben nicht gleich Cluster, soll heißen die Erweiterung des Clusters verletzt die erforderliche strike Typisierung der Funktion "Aufruf über Referenz".

Hat jemand eine Idee wie das gehen könnte ?

Gruß,
JATler


RE: strike Typisierung vs variable Anschlüsse - GerdW - 19.10.2017 14:51

Hallo jat,

du könntest ja mal probieren, mit Variants zu arbeiten.
So sollte dein Interface immer gleich bleiben, du musst dann aber den Variant immer umwandeln, um damit zu arbeiten...


RE: strike Typisierung vs variable Anschlüsse - JATler - 19.10.2017 15:06

Hallo GerdW,

meinst du so (siehe Anhang)?

zur Erklärung:
links, der "ausbaufähige" Anschluß für die VI's
rechts oben, ein "altes" VI, das sich die ersten drei Elemente aus dem Cluster nimmt
rechts unten, ein "neueres" VI, das sich bereits ein weiteres Element aus dem Cluster nimmt
nicht dargestellt, "neuestes" VI, das alle Elemente des Clusters nutzt

in den Variant-Signalpfad würde der dynamische VI-Aufruf hineinkommen und in den aufgerufenen VI's die entsprechende Aufschlüsselung

für den precompiler ist es ok, keine Fehler, der Run-Pfeil ist nicht zerbrochen, aber zur Laufzeit kommen Errors (91)


RE: strike Typisierung vs variable Anschlüsse - GerdW - 19.10.2017 19:30

Hallo JATler,

Zitat:aber zur Laufzeit kommen Errors (91)
Das sagt LabVIEW: "Fehler 91 bei nicht identifizierter Position Mögliche Ursachen: LabVIEW: Der Datentyp des Variant ist nicht kompatibel mit dem Datentyp, der mit dem Eingang verbunden ist."
Du musst natürlich überall mit exakt demselben Cluster arbeiten. Am einfachsten eine Typdefinition verwenden…

Außerdem: Profil_ergaenzen


RE: strike Typisierung vs variable Anschlüsse - Freddy - 20.10.2017 09:34

Hallo Jat,
wenn Du es etwas flexibler haben möchtest, dann versuch es mal wie in meinem Beispiel. Da kannst Du Jederzeit eine weitere Variable einbinden ohne alte VI's zu verändern.
Natürlich sollte immer eine Typdefinition erstellt werden, macht sich leichter.

Gruß
Freddy


RE: strike Typisierung vs variable Anschlüsse - GerdW - 20.10.2017 09:51

Hallo JATler,

Freddys Vorschlag mit den Variantattributen ist auch sehr schön.

Was weiter oben nicht ganz klar rüberkam:
Du kannst zwar beliebige Dinge in den Variant hineinschieben, aber du musst eben an beiden Enden der Verbindung den gleichen Datentyp verwenden. Wenn VI A einen DBL-Wert erwartet, musst du den in den Variant reinschreiben. Wenn VI B einen Errorcluster erwartet, musst du den vorher reinschreiben. Der Vorteil ist halt nur, dass der Aufrufmechanismus für deine verschiedenen VIs identisch bleibt.
Bei Freddys Variante ist das ebenso: du kannst jedem Attribut einen anderen Datentyp zuweisen, aber die Ausleseroutine muss wissen, welchen Datentypen sie im jeweiligen Attribut vorfinden wird/will…


RE: strike Typisierung vs variable Anschlüsse - JATler - 20.10.2017 10:01

Hallo,

danke für eure Antworten.

@GerdW:
das ist ja gerade mein Problem, zu den Daten die ich mit "Aufruf über Refernz" übergeben will werden in der Zukunft welche hinzukommen! Ich suche eine Möglichkeit diese erweitern zu können ohne die strikte Typisierung zu verletzten und alle alten VI's an die Erweiterung anpassen zu müssen. Also exakt der selbe Cluster ist es gerade nicht, das ist ehr das Problem.

Und, was soll ich denn im Profil aktualisieren (ist ernst gemeint die Frage, es gibt doch nichts neues zu mir)?


@Freddy:
... das probier ich aus, sieht jedenfalls nach einer Möglichkeit aus

Gruß,
JATler


RE: strike Typisierung vs variable Anschlüsse - jg - 20.10.2017 10:04

Wo bleiben eigentlich die OOP-ler.

Gruß, Jens


RE: strike Typisierung vs variable Anschlüsse - GerdW - 20.10.2017 11:53

Hallo JATler,

Zitat:Ich suche eine Möglichkeit diese erweitern zu können ohne die strikte Typisierung zu verletzten und alle alten VI's an die Erweiterung anpassen zu müssen. Also exakt der selbe Cluster ist es gerade nicht, das ist ehr das Problem.
Das ist das Problem mit der strikten Typisierung: LabVIEW achtet da sehr darauf!
Möglichkeiten, die ich da sehe:
- ohne Variant arbeiten, dafür mit einem typdefnierten Cluster: es gibt nur eine einzige Stelle, die du anpassen musst, nämlich diese Typdefinition.
- mit Variant arbeiten: auch hier am besten mit einem typdefinierten Cluster wieder in "lesbare" Daten umwandeln. Sowas kann man mehrstufig machen in Abhängigkeit von deiner "Evolution": mit API-Version 1 wird in Cluster1 gewandelt, wenn ein Fehler dabei auftritt, wird eben der Cluster2 für API-Version 2 probiert usw. Man erstellt sich eben ein subVI, welches diese Umwandlung erledigt.
- mit den Variantattributen arbeiten: hier könnte man über die Attribut-Label ("Keys") ja auch gleich den Datentyp kenntlich machen…
- deine bisherigen VIs in die Tonne treten und nochmal sauber von vorn anfangen… Big Grin
- wie von Jens vorgeschlagen, mit OOP/Vererbung arbeiten…

Zitat:Und, was soll ich denn im Profil aktualisieren (ist ernst gemeint die Frage, es gibt doch nichts neues zu mir)?
Im Profil erwähnst du LV2013, hast aber ein VI mit LV2017 angehangen. Deshalb Profil_ergaenzen


RE: strike Typisierung vs variable Anschlüsse - JATler - 20.10.2017 12:01

Hallo,

ich habe Freddys Hinweis mal adaptiert. Die Cluster waren ja sozusagen auch nur ein Ansatz das Problem zu lösen, deswegen jetzt mal ohne Cluster. Zwei Fragen dazu:

1. Ich kann auf diese Weise also mir aus dem Variant immer nur die Daten rausholen, die ich brauche, natürlich muss ich Namen und Typ kennen und somit problemlos neue Daten hinzufügen ohne alte VI's anpassen zu müssen ?

2. Funktioniert das auch mit dem "Aufruf über Referenz" (strikte Typisierung), schließlich verändert sich der Inhalt bzw. die Struktur des Variants ja ?


Ich hatte zwischenzeitlich eine andere Idee: die Umwandlung in eine Daten-String mittels "Daten serialisieren". Was haltet ihr davon ? Könnte das funktionieren ? Vorteile <> Nachteile ?

Gruß,
JATler