Hallo alle zusammen, Ich habe folgende Problem: Ich möchte zwei DLL (File, die von einander abhangig sind) mit Labview einbinden. Diese beide DLL File sind in C++ geschrieben(in Visual Studio 2008). Meine erste Frage: Wie aufwendig ist das denn für jemenden, der keine Erfahrung mit Labview hat? Ich habe Erfahrung nur in C++ bzw. c , Matlab und java. Zweite Frage: Wie soll ich ambesten vorgehen? Dritte Frage: Laut Google ist eine Wrapper notwendig? Danke in voraus
Niko schrieb: > Wie aufwendig ist das denn für jemenden, der keine Erfahrung mit Labview > hat? Normalerweise : Nein. Niko schrieb: > Wie soll ich ambesten vorgehen? Du hast hoffentlich die .h Datei, dann würde ich den Import-Assistenten erstmal verwenden. Nur das: Niko schrieb: > zwei DLL (File, die von einander abhangig sind) ist etwas unklar. Wie würdest Du denn die DLLs in C einbinden so das die voneinander erfahren?
lalala schrieb: > Normalerweise : Nein. bezogen auf welche Frage? lalala schrieb: > ist etwas unklar. Wie würdest Du denn die DLLs in C einbinden so das die > voneinander erfahren? Diese DLL sind in C++ geschrieben und nicht in c. Die Header File habe ich alle nur die Frage der Machtbarkeit ? beide DLL File beinhalten Klassen und komplexe Datenstrukturen, die vielleicht für Labview nicht erkennbar sind.
Niko schrieb: > lalala schrieb: >> Normalerweise : Nein. ich meinte: nicht sehr aufwendig. Niko schrieb: > Diese DLL sind in C++ geschrieben und nicht in c. Das ist ziemlich egal. Du hast meine Frage leider nicht beantwortet. Wie würdest Du denn die beiden dlls in C++ einbinden.
Angehängte Dateien:
-
Architektur.PNG
22 KB
lalala schrieb: > Wie > würdest Du denn die beiden dlls in C++ einbinden? Ich bin so vorgegangen: DLL 1 ist das unterste Schicht in VStudio dann DLL2 ist der zweite Schicht dann meine Main_Object "GUI", wo ich die beide DLL 1 und DLL 2 aufrufe. beide DLL File sind in der C++ ale eigene Projeckt
Wer lädt denn DLL2? Macht DLL1 das, oder Dein 'GUI'-Objekt? Deine Beschreibung ist leider nicht sehr klar.
Ich würde ein C-Style Funktionsinterface einbauen, das den C++ Teil wegkapselt. Damit kannst du dann in labVIEW arbeiten. Die C++ Klassen wirst du nicht in labVIEW verwenden können.
Boris P. schrieb: > Ich würde ein C-Style Funktionsinterface einbauen, das den C++ > Teil > wegkapselt. Damit kannst du dann in labVIEW arbeiten. > > Die C++ Klassen wirst du nicht in labVIEW verwenden können. Ich habe über 20 Klassen. Soll ich für die alle eine Wrapper schreiben? Ich brauche eigentlich nur eine Funktionalität, die ich gerne visualisieren möchte.
Niko schrieb: > Ich habe über 20 Klassen. > Soll ich für die alle eine Wrapper schreiben? Kommt drauf an. Wenn du die Allokation kapselst und über Kenntnis des ABI's den sonst impliziten this-Pointer explizit übergibst, könnte es auch "direkt" funktionieren. Gibt halt wegen des Name Manglings lustige Funktionsnamen.
Niko schrieb: > Ich habe über 20 Klassen. > Soll ich für die alle eine Wrapper schreiben? Nein, nur für die Funktionalität die du brauchst.
Boris P. schrieb: > Ich würde ein C-Style Funktionsinterface einbauen, das den C++ Teil > wegkapselt. Damit kannst du dann in labVIEW arbeiten. > > Die C++ Klassen wirst du nicht in labVIEW verwenden können. Diese C-Style Funktionsinterface sollte für das ganze Dll2 File gültig oder? Das heisst wenn ich in dieses DLL File 20 Klassen habe, muss ich die dann alle in einem C-Style Funktionsinterface umschreiben. liege ich richtig?
Niko schrieb: > Das heisst wenn ich in dieses DLL File 20 Klassen habe, muss ich die > dann alle in einem C-Style Funktionsinterface umschreiben. Das ist doch Käse. C++ ist auch keine Magie, das basiert auf den gleichen Techniken wie C, insbesondere das ABI. Durch Aufrufen der richtigen Funktionen mit den richtigen Parametern kannst du auch eine C++ DLL direkt verwenden. Interessant wäre halt zu wissen, welche Möglichkeiten LabView hier überhaupt bietet. Einfach nur exportierte DLL-Funktionen aufrufen und Integer übergeben? Dann spricht doch wenig dagegen, einfach Instanz-Zeiger mitzuübergeben und somit Memberfunktionen aufzurufen.
Angehängte Dateien:
-
Unbenannt.PNG
32 KB
Dr. Sommer schrieb: > Das ist doch Käse. C++ ist auch keine Magie, das basiert auf den > gleichen Techniken wie C, insbesondere das ABI. Durch Aufrufen der > richtigen Funktionen mit den richtigen Parametern kannst du auch eine > C++ DLL direkt verwenden. Interessant wäre halt zu wissen, welche > Möglichkeiten LabView hier überhaupt bietet. Einfach nur exportierte > DLL-Funktionen aufrufen und Integer übergeben? Dann spricht doch wenig > dagegen, einfach Instanz-Zeiger mitzuübergeben und somit > Memberfunktionen aufzurufen. Ich verstehe nicht ganz was du meinst. Sorry Wenn ich meine DLL (wie es jetzt ist(in C++)) importiere, kann ich einfach keine Funktion selektieren.
Niko schrieb: > Wenn ich meine DLL (wie es jetzt ist(in C++)) importiere, kann ich > einfach keine Funktion selektieren. Sind denn die Funktionen die du aufrufen willst korrekt exportiert in der DLL? Hab grad nicht 100% im kopf wie das unter Windows ging, ich meine man musste __declspec(dllexport) oder sowas dranschreiben.
Niko schrieb: > Ja das habe ich auch so gemacht Zeigen. Nimm mal Depwal ( http://www.dependencywalker.com/ ) um zu sehen ob der die exportierten Funktionen anzeigt.
Dr. Sommer schrieb: > Zeigen. Nimm mal Depwal ( http://www.dependencywalker.com/ ) um zu sehen > ob der die exportierten Funktionen anzeigt Du hast vollkommen recht. Es wurde nichts exportiert. Ich mache es betimmt was falsch.
meine c++ code anhand einen beispiel sieht so aus:
1 | namespace MathFuncs |
2 | {
|
3 | class MathFuncsDll |
4 | {
|
5 | public:
|
6 | // Returns a + b
|
7 | static __declspec(dllexport) double Add(double a, double b); |
8 | |
9 | // Returns a - b
|
10 | static __declspec(dllexport) double Subtract(double a, double b); |
11 | |
12 | // Returns a * b
|
13 | static __declspec(dllexport) double Multiply(double a, double b); |
14 | |
15 | // Returns a / b
|
16 | // Throws DivideByZeroException if b is 0
|
17 | static __declspec(dllexport) double Divide(double a, double b); |
18 | };
|
19 | }
|
Niko schrieb: > meine c++ code anhand einen beispiel sieht so aus: Sieht eigentlich gut aus. Das ist ja schon fast ein un-OOP-C API, da kannst eigentlich gar nichts wrappen. Dann muss beim Compiler etwas falsch eingestellt sein.
Ähh, das sind Methoden, keine Funktionen. Die kannst du nicht exportieren! Wie sollen die auch aufgerufen können ohne Objektinstanz? Nicht umsonst habe ich dir einen C-style Funktionswrapper empfohlen. Dr. Sommer schrieb: > Dann muss beim Compiler etwas > falsch eingestellt sein. Ich denke nicht...
:
Bearbeitet durch User
Boris P. schrieb: > Ähh, das sind Methoden, keine Funktionen. Die kannst du nicht > exportieren! In C++ sagt man lieber Member-Funktion statt Methode. Und ja, die kann man selbstverständlich exportieren, wie das zB die Microsoft-eigenen MFC-DLLs machen. > Wie sollen die auch aufgerufen können ohne Objektinstanz? Indem man eine anlegt und den Pointer darauf als 0. Parameter übergibt. Da Niko's Member-Funktionen aber statisch sind gibt es keine Instanz. > > Nicht umsonst habe ich dir einen C-style Funktionswrapper empfohlen. Das macht aber 0 Sinn, denn was würde dieser Wrapper genau tun? Gar nichts, nur den Code verkomplizieren. > > Dr. Sommer schrieb: >> Dann muss beim Compiler etwas >> falsch eingestellt sein. > > Ich denke nicht Ich denke doch, denn der Code ist korrekt.
Dr. Sommer schrieb: > Indem man eine anlegt und den Pointer darauf als 0. Parameter übergibt. > Da Niko's Member-Funktionen aber statisch sind gibt es keine Instanz. Wie kannst du denn in labVIEW Objekte einer Klasse instanziieren? So wie ich das sehe, geht das nur über die eingebundene DLL. Dr. Sommer schrieb: > Das macht aber 0 Sinn, denn was würde dieser Wrapper genau tun? Gar > nichts, nur den Code verkomplizieren. Z.B. das Instanziieren bzw. Aufräumen des Objekts übernehmen.
Boris P. schrieb: > Wie kannst du denn in labVIEW Objekte einer Klasse instanziieren? Entweder: 1) Aufruf einer Factory Funktion in der DLL die eine Instanz anlegt und einen Pointer zurückliefert - die Standardmethode die von vielen C++ Libraries verwendet wird 2) Anlegen des Speichers und Aufruf des Konstruktors. Erfordert Kenntnis über die Größe des Objekts, kann aber effizienter sein wenn man das Objekt auf den Stack packt o.ä. Eher hässlich, sollte man nur tun wenn wirklich erforderlich. Boris P. schrieb: > So wie ich das sehe, geht das nur über die eingebundene DLL. Logischerweise. Boris P. schrieb: > Z.B. das Instanziieren bzw. Aufräumen des Objekts übernehmen Ah. Dein Instanziieren entspricht vermutlich der Factory Funktion - die ist aber nicht wirklich ein C Wrapper sondern einfach eine freie oder statische Member- Funktion. Wenn man das so macht ist es tatsächlich sinnvoll auch eine Löschfunktion vorzusehen die den Speicher freigibt und den Destruktor aufruft. Wenn man oben 2) gemacht hat ruft man direkt ohne Wrapper den Destruktor auf und löscht den Speicher selber. Das heißt also man kapselt ausschließlich die (de) allokation in freie/statische Member-Funktionen. Der Rest der Funktionalität kann bleiben wie er ist, d.h. die Member-Funktionen ruft man einfach direkt auf. Kein Grund für C-Wrapper.
Mich interessiert immer noch wie er denn an diese exportierten Member der Klasse in seinem C++ Code herankommt.
Hallo alle zusammen, Boris P. schrieb: > Wie läuft's bei Niko? Die Methoden können von Labview gelesen werden seh Bild1. Ich kann leider die Methoden nicht ausführen seh bitte Bild2. Da ich neuling in Labview bin, weiss es nicht was habe ich falsch gemacht.
Niko schrieb: > Ich kann leider die Methoden nicht ausführen seh bitte Bild2. Mit demselben DLL Code? Mit geändertem DLL Code?
Angehängte Dateien:
-
Bild3.PNG
27 KB
bei alle drei Methoden, kann ich keine Funktion ausführen. seh bitte Bild3.
lalala schrieb: > Mich interessiert immer noch wie er denn an diese exportierten > Member > der Klasse in seinem C++ Code herankommt. Habe mal schnell ein Beispiel zusammengecodet. Zum Anlegen der Instanz ruft man die exportierte Funktion "_ZN4Test12makeInstanceEid" auf und merkt sich den 64bit-Rückgabewert (=Pointer), der die Instanz darstellt. Zum Aufruf der calculate-Funktion die exportierte Funktion "_ZN4Test9calculateEd" aufrufen, als 0. Parameter den Instanz-Pointer übergeben, als 1. Parameter einen double. Um getX/getY zu aufzurufen ruft man die exportierten _ZN4Test4getXEv / _ZN4Test4getYEv auf und übergibt den Instanz-Pointer. Zum Löschen ruft man ZN4Test14deleteInstanceEPS auf und übergibt ebenfalls die Instanz. Die Funktionsnamen sehen wegen des Name Mangling wie gesagt etwas lustig aus, die von mir genannten entstehen bei der Verwendung vom GCC, wenn man Visual Studio verwendet kommen vermutlich andere raus; muss man sich dann zB mit Depwalk anschauen. Das ganze wie man sieht ohne irgendwelchen "C-Wrapper".
Dr. Sommer schrieb: > Die Funktionsnamen sehen wegen des Name Mangling wie gesagt etwas lustig > aus, die von mir genannten entstehen bei der Verwendung vom GCC, wenn > man Visual Studio verwendet kommen vermutlich andere raus; muss man sich > dann zB mit Depwalk anschauen. Sollten die Funktionsnamen nicht unabhängig vom Compiler sein? Ich kenne DLL-Exports nur so, dass der Name der Funktion dem entspricht, was man auch im Code vergeben hat. Ansonsten ist der Ärger doch schon vorprogrammiert???
Boris P. schrieb: > Sollten die Funktionsnamen nicht unabhängig vom Compiler sein? Leider sind die nirgends wirklich standardisiert. Ich meine aber sein dass der GCC hier das Schema vom Visual Studio nachmacht, ich weiß es gerade nicht und hab auch grad kein VS zur Hand. > Ich kenne > DLL-Exports nur so, dass der Name der Funktion dem entspricht, was man > auch im Code vergeben hat. Das geht aber nicht, da zB "Test::deleteInstance(Test*)" kein gültiges Linker-Symbol ist, "_ZN4Test14deleteInstanceEPS_" hingegen schon. > Ansonsten ist der Ärger doch schon vorprogrammiert??? Jup...
Dr. Sommer schrieb: > Das geht aber nicht, da zB "Test::deleteInstance(Test*)" kein gültiges > Linker-Symbol ist, "_ZN4Test14deleteInstanceEPS_" hingegen schon. Das wäre doch schon mal ein Grund nicht auf exportierte Methoden zurückzugreifen, sondern doch ein C-Style Interface zu verwenden, oder?
Boris P. schrieb: > Das wäre doch schon mal ein Grund nicht auf exportierte Methoden > zurückzugreifen, sondern doch ein C-Style Interface zu verwenden, oder? Naja, das Schema wird sich so schnell nicht ändern (dann wären ja alle Windows-DLL's nicht mehr nutzbar). Wenn es unbedingt sein muss kann man da noch dumme extern "C" -Wrapper drum machen damit das Symbol einen "definierten" Namen hat, aber eigentlich gibt es keinen wirklichen technischen Grund nicht einfach "_ZN4Test14deleteInstanceEPS_" aufzurufen.
ich habe so meine Code(C++) so angepasst, dass es so aussieht.
[c]
class MyMathFuncs
{
public:
// Returns a + b
__declspec(dllexport)double Add(double a, double b);
// Returns a - b
__declspec(dllexport)double Subtract(double a, double b);
// Returns a * b
__declspec(dllexport)double Multiply(double a, double b);
// Returns a / b
// Throws const std::invalid_argument& if b is 0
__declspec(dllexport)double Divide(double a, double b);
};
[/]
ich habe so meine Code(C++) so angepasst, dass es so aussieht.
1 | class MyMathFuncs |
2 | {
|
3 | public:
|
4 | // Returns a + b
|
5 | __declspec(dllexport)double Add(double a, double b); |
6 | |
7 | // Returns a - b
|
8 | __declspec(dllexport)double Subtract(double a, double b); |
9 | |
10 | // Returns a * b
|
11 | __declspec(dllexport)double Multiply(double a, double b); |
12 | |
13 | // Returns a / b
|
14 | // Throws const std::invalid_argument& if b is 0
|
15 | __declspec(dllexport)double Divide(double a, double b); |
16 | };
|
Niko schrieb: > @Autor: Dr. Sommer (Gast) > > was mache ich dann falsch? Tja mit LabView kenne ich mich auch nicht so aus. Ich hab mal deinen Code bei mir compiliert (einmal 32bit einmal 64bit) und die DLL's angehängt. Die Funktionen werden definittiv exportiert. Versuch mal aus der DLL die Funktion "_ZN9MathFuncs12MathFuncsDll3AddEdd" aufzurufen. Das sollte funktionieren, wenn nicht ist das ein LabView-spezifisches Problem...
@Dr. Sommer (Gast) Kannst du mir bitte noch den Header file noch zuschicken?
Niko schrieb: > @Dr. Sommer (Gast) > Kannst du mir bitte noch den Header file noch zuschicken? Was? Braucht LabView einen Header? Das ändert die Sache... Der Header wäre einfach das:
1 | namespace MathFuncs |
2 | {
|
3 | class MathFuncsDll |
4 | {
|
5 | public:
|
6 | // Returns a + b
|
7 | static __declspec(dllexport) double Add(double a, double b); |
8 | |
9 | // Returns a - b
|
10 | static __declspec(dllexport) double Subtract(double a, double b); |
11 | |
12 | // Returns a * b
|
13 | static __declspec(dllexport) double Multiply(double a, double b); |
14 | |
15 | // Returns a / b
|
16 | static __declspec(dllexport) double Divide(double a, double b); |
17 | };
|
18 | }
|
Angehängte Dateien:
-
Bild3.PNG
27 KB
exportieren kann ich schon aber eben nur 3 Funktionen, die wie
folgenden:
Divide
Multiply
Subtract
warum nicht die Add Funktion weiss es nicht.
das ist auch den Report, die ich dazu bekomme:
VI Not Executable
The VI is not executable because of one of the following reasons:
1. The shared library or a dependent file is not installed. To make the
VI executable, you must install the shared library and all support files
on the computer on which you run the VI.
2. A required custom control might be empty or cannot be found. To make
the VI executable, update the custom control manually.
3. The VI contains a parameter with an unsupported data type. To make
the VI executable, you must replace the empty cluster that the wizard
generates with a control or indicator that uses supported data types.
Divide.vi
Multiply.vi
Subtract.vi
--> Ich kann gar keine Funktionen in Labview ausführen bitte seh Bild3
Fazit: Das DLL als C++ lässt sich leider nicht exportieren Folgende ànderung habe ich gemacht : Header File
1 | extern "C" __declspec(dllexport)double Addi(double a, double b); |
2 | |
3 | // Returns a - b
|
4 | extern "C" __declspec(dllexport)double Subtract(double a, double b); |
5 | |
6 | // Returns a * b
|
7 | extern "C" __declspec(dllexport)double Multiply(double a, double b); |
8 | |
9 | // Returns a / b
|
10 | // Throws const std::invalid_argument& if b is 0
|
11 | extern "C" __declspec(dllexport)double Divide(double a, double b); |
c.File
1 | double Addi(double a, double b) |
2 | {
|
3 | return a + b; |
4 | }
|
5 | |
6 | double Subtract(double a, double b) |
7 | {
|
8 | return a - b; |
9 | }
|
10 | |
11 | double Multiply(double a, double b) |
12 | {
|
13 | return a * b; |
14 | }
|
15 | |
16 | double Divide(double a, double b) |
17 | {
|
18 | if (b == 0) |
19 | {
|
20 | throw invalid_argument("b cannot be zero!"); |
21 | }
|
22 | |
23 | return a / b; |
24 | }
|
--> Resultat : Dieses DLL kann ich mit Labview exportieren Meine Frage: Dieses Testprojekt ist nur als Test gedacht wie soll ich denn machen in meinem Projekt, der über 30 Klassen als in einem C-Style umschreiben???? Hat jemenden Erfahrung mit einen export von "C++ DLL" Danke in voraus.
Niko schrieb: > Dieses DLL kann ich mit Labview exportieren Dann macht LabView da komische Dinge. Auf "binärer" Ebene ist 0 Unterschied zwischen beiden DLL's, nur die Namen der Funktionen sind anders. Keine Ahnung wie man LabView dazu bringt einfach eine gegebene Funktion aufzurufen :-/
Dr. Sommer schrieb: > Unterschied zwischen beiden DLL's, nur die Namen der Funktionen sind > anders Ich habe der Funktionsname von "Add" zu "Addi" geändert weil ich gedacht habe.Es könnte vielleicht einen Fehler sein, weil es Schlüsselwort sein kann. Fazit: Änderung der name hat nichts gebracht und das ist gültig für die C++ DLL export.
Lies mal den Namen mit Dependency Walker aus und trage ihn manuell in den Lib-Node von Labview ein. Das ist unschön, sollte aber gehen.
Einen schönen guten Morgen Zusammen, ich bin gestern Abend im Internet auf folgende Seite: "http://labviewwiki.org/DLL/shared_library"; gestossen. Ich könnte dieses Beispiel bei mir in Visual Studio abbilden und daraus einen DLL erstellen.Dann habe ich in Labview importiert. Es funktioniert alles so weit so gut. Nur mir ist nicht klar wie ich dieses Beispiel in Labview zum laufen bringe?
Moin Moin, ich habe folgende Seite als Einstieg gefunden https://decibel.ni.com/content/docs/DOC-9076 Selbst arbeite ich schon seit Jahren mit LabView (verschiedenste Versionen). Wichtig ist vor allem das die DLL keine Pointer auf Pointer haben (Dies kann man zwar in "nachbilden", macht aber keinen besonderen Spaß :-)) Callbacks sind generell nicht möglich.
@Florian Kulling Danke Es hat mit diesem demo Projekt alles funktioniert. In meinem Projekt sieht die lage etwas anders aus. Ich habe zwei DLL File die eigentlich von einander abhängig sind. Das DLL2 wird von DLL 1 gebraucht. Die Funktionalität, die ich brauche befindet sich In DLL2. Ich weiss es nicht wie ich am besten vorgehen soll? Soll ich für jeden DLL eine Labview Import mit den nötigen DLLWrapper und dann die Funktionen mit Labview konfigurieren? Wenn ich nur für DLL1 einen Labview Import mache (und bestimmte funktionalität von DLL1 gebraucht sind), dann funktioniert das ganze bestimmt nicht. Ist meine vorhaben überhaupt machbar?
Noch eine Frage Bitte: Beim DLL Erstellung(Visual Studio): Spielt eine Rolle, ob der DLL von eine Release Version oder Debug Version ist?
Hallo zusammen, ich wuerde mich hier auch gerne einbringen. Ich habe mir das Problem mal angesehen und wuerde gerne die DLL (von Dr. Sommer) in LabVIEW einbinden, um ein Ergebnis praesentieren zu koennen. Leider meckert LabVIEW beim importieren, dass die Datei LIBGCC_S_SJLJ-1.DLL fehlt. Dependency Walker meldet mir, dass dllclass32.dll von LIBGCC_S_SJLJ-1.DLL abhaengig ist, diese aber auf meinem System fehlt. Kannst Du diese noch zu Verfuegung stellen? Danke! MfG balze
Niko schrieb: > Noch eine Frage Bitte: > Beim DLL Erstellung(Visual Studio): > Spielt eine Rolle, ob der DLL von eine Release Version oder Debug > Version ist? Lustige Frage. Ich denke, dass Du sie Dir selbst beantworten kannst wenn Du drueber nachdenkst. Bei entsprechenden (Vor-)Einstellungen in VC ist die Release Version die endgueltige Version ohne Debug Moeglichkeiten. Die Debug-Version enthaelt die Moeglichkeit ihr mit einem Debugger bei der Arbeit zuzusehen. Funktionieren muessen in LabIEW beide. MfG balze
@Avr Noob Danke :-) Avr Noob schrieb: > Lustige Frage. Ich denke, dass Du sie Dir selbst beantworten kannst wenn > Du drueber nachdenkst. Ich weiss es was für einen Unterschied zwischen debug und Release Version. Aber die Frage war bezogen auf Labview. Hat Labview Problem mit einem DLL (Release) oder DLL(Debug)? Was ist besser? Avr Noob schrieb: > Funktionieren muessen in LabIEW beide. eben nicht warum weiss ich nicht, deswegen kam die Frage.
Niko schrieb: > @Avr Noob Danke :-) > Avr Noob schrieb: >> Lustige Frage. Ich denke, dass Du sie Dir selbst beantworten kannst wenn >> Du drueber nachdenkst. > > Ich weiss es was für einen Unterschied zwischen debug und Release > Version. > Aber die Frage war bezogen auf Labview. > Hat Labview Problem mit einem DLL (Release) oder DLL(Debug)? > Was ist besser? Ich bin kein DLL Experte. Release sollte kleiner und evtl. sogar schneller sein. Debug laesst sich debuggen. Das ist sehr viel besser, wenn man ein Problem hat und debuggen muss. Du kannst LabVIEW auch beibringen die DLL in VC zu debuggen. Ist ein bisschen tricky, geht aber. Dazu musst Du 1. die von Dir erzeugte Debug Version der DLL in Dein LabVIEW Projekt einbinden 2. LabVIEW als Debugwergzeiug in VC einstellen 3. Deinen Labviewcode ausfuehren, der die DLL benutzt. Der DLL Aufruf fuehrt dann zum Debuggen der DLL in VC. > Avr Noob schrieb: >> Funktionieren muessen in LabIEW beide. > > eben nicht Eben doch! Es gibt (AFAIK) keinen Grund, warum die eine laufen soll und die andere nicht. Ich lasse mich aber gerne eines Besseren belehren!
:
Bearbeitet durch User
Avr Noob schrieb: > Ich habe mir das Problem mal angesehen und wuerde gerne die DLL (von Dr. > Sommer) in LabVIEW einbinden, um ein Ergebnis praesentieren zu koennen. Ja das wär cool. > Leider meckert LabVIEW beim importieren, dass die Datei > LIBGCC_S_SJLJ-1.DLL fehlt. Hubbs, vergessen. Da sind Hilfsfunktionen von der C-Umgebung von MinGW drin. Hab mal die aus meiner (der Ubuntu-) MinGW Distribution angehängt (32 & 64 bit). Avr Noob schrieb: > Funktionieren muessen in LabIEW beide. Kommt drauf an, nur wenn auf dem Zielsystem alle DLL's, die von der Debug-Version gebraucht werden, installiert sind; wenn Visual Studio installiert ist ist das der Fall, sonst nicht unbedingt. Die von der Release-Version benötigten DLL's sollten aber überall installiert sein, wimre. Niko schrieb: > Was ist besser? Da du aus LabVIEW eh nicht debuggen kannst bietet die Debug-Version wohl kaum Vorteile, während die Release-Version schneller&kleiner ist und auch auf jedem Windows funktionieren sollte.
Angehängte Dateien:
-
process_anhaengen.png
49 KB
Dr. Sommer schrieb: > Avr Noob schrieb: >> Ich habe mir das Problem mal angesehen und wuerde gerne die DLL (von Dr. >> Sommer) in LabVIEW einbinden, um ein Ergebnis praesentieren zu koennen. > Ja das wär cool. >> Leider meckert LabVIEW beim importieren, dass die Datei >> LIBGCC_S_SJLJ-1.DLL fehlt. > Hubbs, vergessen. Da sind Hilfsfunktionen von der C-Umgebung von MinGW > drin. Hab mal die aus meiner (der Ubuntu-) MinGW Distribution angehängt > (32 & 64 bit). Danke, probiere ich aus! > Avr Noob schrieb: > Niko schrieb: >> Was ist besser? > Da du aus LabVIEW eh nicht debuggen kannst bietet die Debug-Version wohl > kaum Vorteile, während die Release-Version schneller&kleiner ist und > auch auf jedem Windows funktionieren sollte. Das stimmt aber nicht. Man kann in Visual Studio (Ich habe nur VC 2010 Express) die Debug DLL an einen Process anhaengen (In VC2010Express -> Strg+Alt+P , dann kommt das Fenster aus dem Anhang.) Startet man nun das LabVIEW VI, wird die DLL im VC Debugger geoeffnet. MfG balze aka AVR Noob
Niko schrieb: > Wenn ich nur für DLL1 einen Labview Import mache (und bestimmte > funktionalität von DLL1 gebraucht sind), dann funktioniert das ganze > bestimmt nicht. Solange sich DLL1 wie Du schreibst selber darum kümmert das DLL2 geladen wird, kann das kein Problem sein.
Angehängte Dateien:
-
DLL_Class_Test.png
13 KB
lalala schrieb: > Niko schrieb: >> Wenn ich nur für DLL1 einen Labview Import mache (und bestimmte >> funktionalität von DLL1 gebraucht sind), dann funktioniert das ganze >> bestimmt nicht. > > Solange sich DLL1 wie Du schreibst selber darum kümmert das DLL2 geladen > wird, kann das kein Problem sein. Das wird erfahrungsgemaess dann ein Problem, wenn man eine Applikation und einen Installer erstellt. LabVIEW ist naemlich leider (immer noch nicht) in der Lage die Abhaengigkeiten zu berueckschtigen, weshalb man als Entwickler selbst dafuer zu sorgen hat (per Hand sozusagen), dass Abhaengige DLLs mit im Installer landen. @ Dr.Sommer. Laeuft! (Das PNG ist mit dem LAVA "Code Capture Tool" erstellt und enthaelt das VI!! (in LV2013) Einfach in leeres LV VI droppen!) LV Function Prototype: double _ZN9MathFuncs12MathFuncsDll3AddEdd(double arg1, double arg2); Die beiden DLLs (dllclass32.dll, libgcc_s_sjlj-1.dll (32bit)) muessen im VI Pfad liegen. MfG balze aka AVR Noob
Avr Noob schrieb: > @ Dr.Sommer. Laeuft! Ha, super ;-) dank dir siehts jetzt nicht so aus als hätt ich nur Unsinn erzählt :o) Avr Noob schrieb: > LV Function Prototype: > double _ZN9MathFuncs12MathFuncsDll3AddEdd(double arg1, double arg2); Genau so war das gedacht.
@Dr.Sommer Kannst du mir bitte deine Quellen Code von deine Example zu verfügung stellen. Ich möchte gucken wie du mit dem Factory gemacht hast? und dann anschliessen in Labview testen. Danke in Voraus
Niko schrieb: > @Dr.Sommer > Kannst du mir bitte deine Quellen Code von deine Example zu verfügung > stellen. Der ist doch oben schon in einzelteilen... Hab ihn hier nochmal zusammen gestellt, alles in einem. Der Ordner "dllclass" im Zip enthält eine DLL die eine C++ Klasse mit Factory und nichtstatischen Funktionen enthält. Der Ordner "dllstatic" im Zip enthält eine DLL die statische Member-Funktionen einer Klasse exportiert, die direkt aufgerufen werden können. Das ist die DLL die Avr Noob (balze) erfolgreich in LabView verwendet hat. Der Ordner libgcc enthält die libgcc DLL die Hilfsfunktionen für die C Runtime enthält, stammt aus MinGW. Alle DLL's jeweils als 32bit und 64bit Version, kompiliert mit MinGW unter Ubuntu.
Dr. Sommer schrieb: > Niko schrieb: >> @Dr.Sommer >> Kannst du mir bitte deine Quellen Code von deine Example zu verfügung >> stellen. > Der ist doch oben schon in einzelteilen... > > Hab ihn hier nochmal zusammen gestellt, alles in einem. > Der Ordner "dllclass" im Zip enthält eine DLL die eine C++ Klasse mit > Factory und nichtstatischen Funktionen enthält. > Der Ordner "dllstatic" im Zip enthält eine DLL die statische > Member-Funktionen einer Klasse exportiert, die direkt aufgerufen werden > können. Das ist die DLL die Avr Noob (balze) erfolgreich in LabView > verwendet hat. > > Der Ordner libgcc enthält die libgcc DLL die Hilfsfunktionen für die C > Runtime enthält, stammt aus MinGW. > > Alle DLL's jeweils als 32bit und 64bit Version, kompiliert mit MinGW > unter Ubuntu. Ich bin LabVIEW Programmierer und kenne mich nur am Rande mit C++ aus. Deshalb meine dumme Frage: Bedeutet "static" nicht auch, dass die Funktion nicht mehr ueberladen werden kann? Das torpediert das Objekt-Orientierte-Konzept aber ordentlich, oder? Ich wollte mir gerne die "echte" Klassenloesung ansehen. Leider fehlt beim Importieren auch hier eine DLL (libstdc++-6.dll). Kann ich die auch noch bekommen? :) MfG balze ak AVR Noob
Avr Noob schrieb: > Ich bin LabVIEW Programmierer und kenne mich nur am Rande mit C++ aus. Na is doch super, sind wir die optimale Beratung bei diesem Problem ;-) > Deshalb meine dumme Frage: > Bedeutet "static" nicht auch, dass die Funktion nicht mehr ueberladen > werden kann? Nö, das geht immer noch:
1 | #include <string> |
2 | |
3 | class Foo { |
4 | public:
|
5 | static void test (int x); |
6 | static void test (double x); |
7 | static void test (std::string x); |
8 | };
|
9 | |
10 | |
11 | int main () {} |
"static" bewirkt nur dass die Funktion nicht zu einer bestimmten Instanz gehört und somit ohne Instanz der Klasse aufgerufen werden kann, ähnlich einer "globalen"(freien) Funktion. > Das torpediert das Objekt-Orientierte-Konzept aber > ordentlich, oder? Naja, SO wichtig sind Überladungen für OOP jetzt nicht, aber sie sind schon praktisch. > Ich wollte mir gerne die "echte" Klassenloesung ansehen. Leider fehlt > beim Importieren auch hier eine DLL (libstdc++-6.dll). Oh, und ich hab noch überlegt ob die gebraucht wird... Ist im Anhang, auch im libgcc Verzeichnis.
Danke Herr Dr. aber das mit dem 0. Parameter funktioniert mit LabVIEW garantiert nicht. Wie kann man denn bei C++ einen Funktionaufruf mit einem zusaetzlichen 0. Parameter machen? MfG balze aka AVR Noob
Avr Noob schrieb: > Danke Herr Dr. > > aber das mit dem 0. Parameter funktioniert mit LabVIEW garantiert nicht. > Wie kann man denn bei C++ einen Funktionaufruf mit einem zusaetzlichen > 0. Parameter machen? Ich glaub ich hab mich blöd ausgedrückt... Mit 0. Parameter meinte ich halt ganz normal den Anfang der Parameterliste:
1 | myFunction (a, b, c, d); |
Hier ist a der 0. Parameter. Für einen Aufruf einer nichtstatischen Member-Funktion ist dieser 0. Parameter eben der Pointer auf die Instanz, der zuvor von der Factory-Funktion zurückgegeben wurde. Und ein Pointer unter x86(_64) ist im Endeffekt nichts anderes als ein 32/64 bit Integer, und die sollte LabVIEW ja verarbeiten können?!
@ Avr Noob Ich habe das lv-dll.zip von Herr.Dr (Danke) ausprobiert. Ich könnte die Funktionen öffnen aber leider nicht konfigurieren. Da ich einen Einsteiger in labview bin fehlen mir die Idee was lauft dann schief...? Ich habe Labview 2012 und der DLL File wurde mit Visual studio 2012 erstellt. anbei ist die das ganze Zip mit allem (VI, DLL und Header ). Danke in voraus.
Diese DLL exportiert gar keine Symbole, da kann also kein Programm irgendwas mit machen, weder LabView noch ein C++ Programm noch sonstwas... Da muss beim Compilieren irgendetwas schief gelaufen sein. Versuch mal meine DLL, die exportiert u.a. folgende Symbole:
1 | 6cbc154c T __ZN4Test12makeInstanceEid |
2 | 6cbc158c T __ZN4Test14deleteInstanceEPS_ |
3 | 6cbc1536 T __ZN4Test4getXEv |
4 | 6cbc1540 T __ZN4Test4getYEv |
5 | 6cbc14e6 T __ZN4Test9calculateEd |
6 | 6cbc14c0 T __ZN4TestC1Eid |
7 | 6cbc14c0 T __ZN4TestC2Eid |
Da müsstest du dann ZN4Test12makeInstanceEid aufrufen können und dabei einen integer und ein double übergeben, den Rückgabewert (der die Instanz darstellt und ein 32/64bit Pointer ist) merken, und den zB an __ZN4Test4getXEv übergeben um getX() auf dieser Instanz aufzurufen.
Angehängte Dateien:
-
DLL_Class_Test.png
13 KB -
DLL_Class_factory_Test.png
28 KB
Moin Moin zusammen, @Dr. Sommer: Laeuft! Das mit dem zusaetlichen Parameter ist mir neu (und ziemlich (!) fremd). Ist das uebliche Vorgehensweise und moeglicherweise auch irgendwo so dokumentiert? Wuerde mich ueber eine Hinweis freuen, wo ich das mal nachlesen koennte. :) @Niko: Versuch doch erstmal die statische DLL zum Laufen zu bringen. Ich habe meine Versionen jetzt fuer LV 12 angehaengt. (Wie gesagt, PNG in leeres VI droppen) MfG balze aka AVR Noob
Avr Noob schrieb: > Moin Moin zusammen, > > @Dr. Sommer: Laeuft! HA, großartig ;-) > Das mit dem zusaetlichen Parameter ist mir neu (und ziemlich (!) fremd). > Ist das uebliche Vorgehensweise und moeglicherweise auch irgendwo so > dokumentiert? Ja, das ist Teil des ABI. Der GCC verwendet wohl das Itanium ABI, MSVC irgendein eigenes komisches... Da muss man ein bisschen Googlen um die richtigen Infos zu finden. Dass der Instanz-Pointer als 0. Paramter übergeben wird ist aber glaubich ziemlich überall so. Im ABI stehen noch jede Menge andere definitionen, z.B. wie die Parameter übergeben werden (Register, Stack), wie Exceptions übergeben werden, wie diese lustigen Funktionsnamen zustande kommen, etc. > @Niko: > Versuch doch erstmal die statische DLL zum Laufen zu bringen. > Ich habe meine Versionen jetzt fuer LV 12 angehaengt. (Wie gesagt, PNG > in leeres VI droppen) Dann wird das bei ihm automatisch importiert?! Ist ja cool. Wenn nicht, kannst du vielleicht deine LabView Dateien mal anhängen damit er einen Ausgangspunkt hat ;-)
>> @Dr. Sommer: Laeuft! > HA, großartig ;-) -> Gutes Team :) > Ja, das ist Teil des ABI. OKAY,..... Ich muss gestehen, dass ich mich noch nie mit ABIs auseinadergesetzt habe. (Hab schliesslich nur die Fachhochschulreife und kein ABI ;-) > Dann wird das bei ihm automatisch importiert?! Ist ja cool. Wenn nicht, > kannst du vielleicht deine LabView Dateien mal anhängen damit er einen > Ausgangspunkt hat ;-) Ja! Das ist saucool! Da haben sich die Leute von LAVA echt was geniales ausgedacht. Das VI ist in den Metadaten des PNG enthalten. Laesst man das PNG auf ein LabVIEW Blockdiagram fallen, wird das VI aus dem PNG extrahiert. Beim Erzeugen kann man dann noch auswaehlen was in die Metadaten soll und fuer welche LabVIEW Version. Eins der pfiffigsten Tools fuer LabVIEW! Absolut GENIAL um Probleme in Foren zu schildern (oder zu loesen)! MfG balze aka AVR Noob
Eine Frage bitte: wo finde ich die Funktionen bzw. das DLL File? 6cbc154c T __ZN4Test12makeInstanceEid 6cbc158c T _ZN4Test14deleteInstanceEPS 6cbc1536 T __ZN4Test4getXEv 6cbc1540 T __ZN4Test4getYEv 6cbc14e6 T __ZN4Test9calculateEd 6cbc14c0 T __ZN4TestC1Eid 6cbc14c0 T __ZN4TestC2Eid Sorry es ist mir peinlich genug
Niko schrieb: Jungeeeeeee > Eine Frage bitte: > wo finde ich die Funktionen bzw. das DLL File? Beitrag "Re: C++ DLL in Labview einbinden" daaa im Anhang > > 6cbc154c T __ZN4Test12makeInstanceEid > 6cbc158c T _ZN4Test14deleteInstanceEPS > 6cbc1536 T __ZN4Test4getXEv > 6cbc1540 T __ZN4Test4getYEv > 6cbc14e6 T __ZN4Test9calculateEd > 6cbc14c0 T __ZN4TestC1Eid > 6cbc14c0 T __ZN4TestC2Eid Die Liste der exportierten Funktionen kann man im Dependency Walker sehen, oder mit "nm" falls man MinGW installiert hat
@Niko: Warum oeffnest Du nicht EINFACH die von mir angehaengte Loesung und siehst es Dir dort an? Warum praesentieren wir die Loesung, wenn sie ignoriert wird? Deshalb: 1. Lade Dir das PNG herunter (DLL_Class_factory_Test.png) 2. Oeffne ein leeres VI mit LV2012 3. Wechsle zum Blockdiagram (Strg+E) 4. Ziehe das PNG mit der Maus auf das Blockdiagram 5. Voilá, des Raetsels Loesung (Evtl. musst Du das VI speichern und neu oeffnen. Und zwar in dem Ordner in dem auch die DLLs liegen!) MfG balze aka AVR Noob
:
Bearbeitet durch User
Angehängte Dateien:
-
Unbenannt.PNG
25 KB
@Avr Noob
und
@ Dr.Sommer
Danke und noch mal Danke....
Avr Noob schrieb:
> 1. Lade Dir das PNG herunter (DLL_Class_factory_Test.png)
> 2. Oeffne ein leeres VI mit LV2012
> 3. Wechsle zum Blockdiagram (Strg+E)
> 4. Ziehe das PNG mit der Maus auf das Blockdiagram
> 5. Voilá, des Raetsels Loesung
>
> (Evtl. musst Du das VI speichern und neu oeffnen. Und zwar in dem Ordner
> in dem auch die DLLs liegen!)
Ich habe genau so gemacht aber leider bekomme ich immer eine
Fehlermeldung.
Seh bitte Anhang.
Angehängte Dateien:
-
Call_Library_Function.png
150 KB
OK, das ist deshalb so, weil der Pfad zur DLL nicht stimmt. Mache einen Doppelklich auf "Call Library Function" (das orange Symbol; der DLL Funktions-Aufruf) [Rechtsklick und "configure" geht auch.] Daraufhin oeffnet sich ein Dialog. In diesem Dialog auf dem Reiter "Function" Musst Du jetzt "Library Name or Path" so anpassen, dass das VI die DLL auf Deinem Rechner findet. Siehe Screenshot MfG balze aka AVR Noob
@Avr Noob Es funktioniert :-) 100000000000000000000 Dank Sorry für die Umstände
Niko schrieb: > @Avr Noob > > Es funktioniert :-) HEUREKA! > Sorry für die Umstände Alles gut, dafuer bin ich hier! :) Frag gerne weiter, wenn Du weitere Probleme hast. MfG, balze aka AVR Noob
> was für Literatur "Labview" kannst du mich empfehlen? keine, da ich keine gelesen habe. Ich arbeite seit vielen Jahren (12) mit LabVIEW. Ein Buch habe ich nicht gebraucht. Als erstes muss man sich im Klaren sein, dass man Software entwickelt! Hier gelten alle Regeln der Kunst, wie bei jeder anderen Programmiersprache auch. Wer LabVIEW fuer ein "Visualisierungtool" haelt liegt falsch! LabVIEW ist eine Programmier..... naja Programmier"sprache". Wenn man sich das klar macht, spart man sich soetwas wie in diesem thread: Beitrag "LabView: Ein einfach SubVI mit Ausgang?" In dem "Das Programm" den TO "noch wahnsinnig macht", er aber keine Ahnung davon hat was er da tut. Weil: kein C-Entwickler wuerde sich darueber wundern, dass das nicht geht:
1 | int get_Zufallszahl(void) |
2 | {
|
3 | int ZFZ; |
4 | while (true) |
5 | {
|
6 | ZFZ = rand(); |
7 | }
|
8 | return ZFZ; |
9 | }
|
10 | |
11 | int main (void) |
12 | {
|
13 | int Zufallszahl; |
14 | while (true) |
15 | {
|
16 | Zufallszahl = get_Zufallszahl(); |
17 | printf("Wert: %d",Zufallszahl); |
18 | }
|
19 | }
|
20 | //Von mir eingebaute C-Syntax-Fehler sind beabsichtigt! ;-)
|
Dafuer wird in solchen threads dann aber schnell ueber die Qualitaet von LabVIEW gemosert und gemotzt. Obwohl das Problem ganz offensichtlich an andere Stelle ist (PEBCAC -> Problem Exists Between Chair And Computer) Beachte, dass LabVIEW "von natur aus" multithreading unterstuetzt. Machst Du zwei Schleifen auf laufen beide parallel (So der Rechner dies zulaesst) Denk darueber nach was Du tust. WICHTIG: Sieh Dir die Beispiele in LabVIEW an!!! Benutze Strg+H fuer die Kontexthife! Diese bringt sehr nuetzliche Infos. Wenn es ein Buch sein soll, empfehlen meine Kollegen dies hier: http://www.hanser-fachbuch.de/buch/Einfuehrung+in+LabVIEW/9783446423862 Ich selbst habe es aber nicht gelesen! MfG balze aka AVR Noob
Nicht in diesen technischen Details, die jetzt bei der DLL helfen würden, aber um schönen (=guten) LabView Code zuschreiben: http://www.amazon.com/LabVIEW-Style-Book-Peter-Blume/dp/0131458353
@Avr Noob Danke noch mal wenn ich dich nochmal Frage: Ich habe oben in diesen Beitrage meine Vorhaben schon geschildert. was würdest du machen?
Niko schrieb: > Ich habe oben in diesen Beitrage meine Vorhaben schon geschildert. > was würdest du machen? Die Frage solltest Du mir nicht stellen. Ich bin LabVIEW Entwickler. Ich haette keine C++ Klassen geschrieben, sondern haette das Problem komplett in LabVIEW geloest. Da Du C++ Klassen hast, solltest Du Dein Problem vielleicht auch mit C++ (Visual Studio) zuende bringen. Du hast Dir fuer Deinen LabVIEW Start eine der schwierigsten (weil beliebig kompliziert) Aufgaben gesucht. Der Aufruf von DLLs in LabVIEW ist schon sehr viel einfacher geworden, birgt aber immer noch viele Probleme (LabVIEW kennt keine Zeiger, hat keine Structs (auch wenn Cluster denen aehneln), kann keine Callbacks, DLLs koennen nicht dynamisch speicher allozieren mit dem LabVIEW hinterher arbeiten kann, ..... tausend andere Fallstricke) Fallstricke gibt es sicherlich in vielerlei Form sicherlich auch in anderen Programmiersprachen. Aber hier schwaechelt LabVIEW schon sehr. Ich weiss nicht wie umfagreich Deine Klassen sind, aber vielleicht lassen sich Deine Klassen ja schnell und einfach in LabVIEW nachbilden. MfG balze aka AVR Noob
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.