INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Dieses Thema hat akzeptierte Lösungen:

strike Typisierung vs variable Anschlüsse



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

19.10.2017, 11:58
Beitrag #1

JATler Offline
LVF-Grünschnabel
*


Beiträge: 18
Registriert seit: Jul 2017

2019
2017
DE


Deutschland
strike Typisierung vs variable Anschlüsse
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


Angehängte Datei(en) Thumbnail(s)
   
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
19.10.2017, 14:51
Beitrag #2

GerdW Offline
______________
LVF-Team

Beiträge: 17.469
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: strike Typisierung vs variable Anschlüsse
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...
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
19.10.2017, 15:06 (Dieser Beitrag wurde zuletzt bearbeitet: 19.10.2017 15:20 von JATler.)
Beitrag #3

JATler Offline
LVF-Grünschnabel
*


Beiträge: 18
Registriert seit: Jul 2017

2019
2017
DE


Deutschland
RE: strike Typisierung vs variable Anschlüsse
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)


Angehängte Datei(en) Thumbnail(s)
   

17.0 .vi  variant.vi (Größe: 12,55 KB / Downloads: 234)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
19.10.2017, 19:30 (Dieser Beitrag wurde zuletzt bearbeitet: 19.10.2017 19:32 von GerdW.)
Beitrag #4

GerdW Offline
______________
LVF-Team

Beiträge: 17.469
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: strike Typisierung vs variable Anschlüsse
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

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
20.10.2017, 09:34
Beitrag #5

Freddy Offline
Oldtimer
****


Beiträge: 729
Registriert seit: Aug 2008

2019, 2020, 2021
1996
DE

76275
Deutschland
RE: strike Typisierung vs variable Anschlüsse
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


Angehängte Datei(en) Thumbnail(s)
   

Einführende Links zu LabVIEW, s. GerdWs Signatur.
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
20.10.2017, 09:51
Beitrag #6

GerdW Offline
______________
LVF-Team

Beiträge: 17.469
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: strike Typisierung vs variable Anschlüsse
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…

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
20.10.2017, 10:01
Beitrag #7

JATler Offline
LVF-Grünschnabel
*


Beiträge: 18
Registriert seit: Jul 2017

2019
2017
DE


Deutschland
RE: strike Typisierung vs variable Anschlüsse
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
20.10.2017, 10:04
Beitrag #8

jg Offline
CLA & CLED
LVF-Team

Beiträge: 15.864
Registriert seit: Jun 2005

20xx / 8.x
1999
EN

Franken...
Deutschland
RE: strike Typisierung vs variable Anschlüsse
Wo bleiben eigentlich die OOP-ler.

Gruß, Jens

Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)

!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!

Einführende Links zu LabVIEW, s. GerdWs Signatur.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
20.10.2017, 11:53 (Dieser Beitrag wurde zuletzt bearbeitet: 20.10.2017 11:54 von GerdW.)
Beitrag #9

GerdW Offline
______________
LVF-Team

Beiträge: 17.469
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: strike Typisierung vs variable Anschlüsse
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

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
20.10.2017, 12:01
Beitrag #10

JATler Offline
LVF-Grünschnabel
*


Beiträge: 18
Registriert seit: Jul 2017

2019
2017
DE


Deutschland
RE: strike Typisierung vs variable Anschlüsse

Akzeptierte Lösung

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


Angehängte Datei(en) Thumbnail(s)
       
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
30
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  Exe Anwendung keine COM-Anschlüsse gefunden Tomy 1 3.726 01.04.2019 16:09
Letzter Beitrag: GerdW

Gehe zu: