Generiere VI's

Hallo *,

besteht i.V. mit Labview grundsätzlich die Möglichkeit VI's modellgetrieben / modellzentriert
generieren zu lassen?

Welche input-Code wird benötigt?
Eventuelle Vorstufen werden bereits eingesetzt:
Activity/State Machine - UML -> Testfallgenerierung über u.U. Borland SilkTest, C/C++/C#, Java, Perl, Python, etc.

Kann LV aus irgendeinem Quellcode z.B. in Verbindung eines externen Programms ein VI bestehend aus G erzeugen?


Gruß arphex

Anzeige

Machbar müsste das, dank LV Scripting, schon sein. Von einem echten Produkt, daß dies Out of the Box macht, habe ich noch nix gesehen/gehört.
Selbst schreiben dürfte recht aufwendig sein.
Da würde ich eher versuchen den vorhandenen Code als .dll o.ä. zu integrieren.

meine 5ct

(08.06.2011 12:30 )macmarvin schrieb:  Machbar müsste das, dank LV Scripting, schon sein. Von einem echten Produkt, daß dies Out of the Box macht, habe ich noch nix gesehen/gehört.
Selbst schreiben dürfte recht aufwendig sein.
Da würde ich eher versuchen den vorhandenen Code als .dll o.ä. zu integrieren.

meine 5ct

Hi,
danke für deine Antwort.
Wie meinst du denn das genau?
Vorhandenen Code gibt es so nicht.
Ich verwende einen Testmanager von MCD:
http://www.mcd-elektronik.de/deutsch/pro...index.html

Da sieht man eben auch das dieser .vi's aufrufen kann.
Funktioniert eigentlich auch alles.
Nun würde ich gerne die ganze Funktionalitäten der .vi's per dll bereitstellen.
Ich kann im Testmanager von MCD .dll's einbinden, nur wie kann ich dll('s) aus .vi's erstellen?

Gruß

(12.07.2011 12:40 )arphex schrieb:  ... nur wie kann ich dll('s) aus .vi's erstellen?

Du kannst prizipiell jedes VI als DLL compilieren.

Grüße
Andreas

Jetzt habe ich noch die Möglichkeit gesehen, die NI-DAQ - Software zu nutzen:

http://digital.ni.com/public.nsf/allkb/E...enDocument

Sprich wenn ich irgendwie die .NET Libs einbinde, spare ich mir dann die .vi's?
Weil die Funktionen an das Gerät (z.B. z.B. PXIe) so direkt senden kann?

Der oben genannte Testmanager kann ja mit .NET umgehen.

Schwierig die ganzen Zusammenhänge per se gleich zu durchschauen.
Danke für die Antworten

(12.07.2011 15:45 )arphex schrieb:  Sprich wenn ich irgendwie die .NET Libs einbinde, spare ich mir dann die .vi's?

Wenn dir da die "nackten" Treiberaufrufe reichen und dein Testmanager sich sonst um alles kümmert, könnte es gehen. Ich glaub's aber eher weniger.

Als Außenstehender ist's aber recht schwer der Diskussion zu folgen. Angefangen hat's mit modellgetriebener Codegenerierung und jetzt sieht's nur noch nach Messen mit NI DAQmx HW aus.

Dabei blieb es auch :-).

Es ist nur die Kette die ich zu einem Kreislauf vervollständigen möchte.

Modelle->Generierung von Code für den Testmanager -> Code beinhaltet jeweils .vi's um die HW anzusprechen.

Ich transformiere mit XSLT das haut schon gut hin.
Die .vi's sind eine spannende Sache und ich mache mich halt schlau wie ich dem Problem begegnen kann.
Dazu habe ich mich eben auch mit der DAQ-SW auseinandergesetzt.

(12.07.2011 16:14 )arphex schrieb:  Modelle->Generierung von Code für den Testmanager -> Code beinhaltet jeweils .vi's um die HW anzusprechen.

Wenn du Labview nur brauchst um NI HW anzusprechen und der Code zum Ansprechnen auch noch generiert sein soll, würde ich drauf tippen, daß da textbasierte Sprachen deutlich leichter zu benutzen sind.

Für Codegenierung ist gerade neue Doku+Code in den NI Labs gepostet worden.
Vielleicht hilft dir das weiter.
LabVIEW Code Generation Engine

Ich habe es übrigens geschafft mein Ziel zu erreichen.

Mit Enterprise Architect habe ich mir eine Umgebung geschaffen einzelne Elemente zu modellieren und Code-Fragmente zu hinterlegen.
Vorteil - hohe Wiederverwendbarkeit und die Review-Eigenschaft im Team ist hervorragend.
Die VI's werden derzeit über den LabViewMidServer angesprochen und über einen COM-Server "befüllt" und "abgefragt".
Funktioniert prima.
Ich versuche mich gerade an der Exportierung der VI-Funktionalitäten in .NET:

http://www.labviewforum.de/Thread-LabVie...n-C-nutzen

Der Kreis schliesst sich langsam