LabVIEWForum.de

Hallo Labview-Profis,

ich bin nach längerer Pause wieder an Labview dran.
Ich habe diesmal eine selbstentwickelte DLL die zur Kommunikation über die serielle Schnittstelle mit einem Mikrocontroller dient.
Diese DLL funktioniert auch korret. Baut eine Verbindung auf und beendet sie am Ende auch wieder korrekt.

Jetzt habe ich diese DLL in mein Labview-Programm mit dem VI "Knoten zum aufruf externer Bibliotheken" eingebunden. Das funktioniert soweit auch gut. Ich kann dann mit meinem Programm die Kommunikation aufbauen und Daten hin und herschicken.
Dabei ist die DLL über zwei Schnittstellen (Funktionen aus der DLL) in Labview eingebunden. Die erste dient zum Kommunikation. Die zweite nur um jederzeit den Status der DLL abzufragen.

Die Kommunikation in Labview (besser gesagt der Aufruf der DLL) wird über einen Button gestartet.
Mein Problem ist jetzt das ich die Kommunikation nur einmal ausführen kann. Ein zweites mal geht es nicht da meine DLL eine Fehlermeldung zurück gibt die besagt das der Port bereits besetzt ist.
Erst wenn ich Labview komplett neustart kann ich wieder aufbauen.
In Labview selbst verwende ich nichts was mit der Kommunikation zu tun hat. Also keine VISA-Schnittstellen oder sonst was. Die ganze Kommunikation läuft ausschließlich über die DLL.

Habt ihr eine Idee an was das liegen könnt das Labview hier die Schnittstelle blockiert?
Wenn ich das nicht umgehen kann gibt es eine Möglichkeit die Schnittstelle im Nachhinein über Labview frei zu geben?

Wär super wenn ihr en paar Tipps hättet
Viele Grüße,
Berdschi

Also für mich hört sich das so an, als ob deine DLL die Schnittstelle nicht frei gibt, solange sie im Speicher ist. Da kann LabVIEW nichts dran ändern und auch nichts dafür.

Gruß, Jens

Das hab ich auch erst gedacht. Aber das ist es definitiv nicht. Ich hab dafür extra mal ein Sniffing-Tool nebenher laufen lassen. Die DLL ruf zum Schluss die Close-Funktion auf und Windows sendet dann auch den entsprechenden Request vom Treiber um die Verbindung zu beenden.

(04.04.2014 13:11 )Berdschi schrieb: [ -> ]Das hab ich auch erst gedacht. Aber das ist es definitiv nicht. Ich hab dafür extra mal ein Sniffing-Tool nebenher laufen lassen. Die DLL ruf zum Schluss die Close-Funktion auf und Windows sendet dann auch den entsprechenden Request vom Treiber um die Verbindung zu beenden.

Und doch macht Deine DLL da irgendwas. LabVIEW kann nicht magisch eine Schnittstelle geöffnet halten nur weil Deine DLL diese irgendwann mal öffnet. LabVIEW weiss nichts darüber was Deine DLL macht und kann dann auch nicht von sich aus etwas tun hier.

Debugging der DLL wird die einzige Möglichkeit sein um das sauber u kriegen. Ohne die DLL und den Source Code davon zu sehen lässt sich so auf Abstand leider nicht viel mehr dazu sagen. Nehme aber von mir mal an, dass das Problem nicht LabVIEW selber ist sondern die Art und Weise wie diese DLL programmiert ist und wie Du sie von LabVIEW aus aufrufst.

Sry das ich mich jetzt erst wieder melde. Ich kam erst jetzt wieder dazu.
Also langsam denk ich auch das es an der DLL liegt.
Leider weiß ich nicht warum. Wie mach ich das den mit dem Debuggen aus Labview raus?

So ich hab den Grund endlich gefunden warum es nicht ging.
Es lag natürlich an der DLL ^^
Wie sich herausgestellt hat, lief der Mikrocontroller beim zweiten Kommunikationsaufbau in einen Fehler. Dieser wurde zwar abgefangen aber das Programm wurde dabei einfach beendet ohne sämtliche offenen Verbindungen zu beenden. Dadurch war dann der Com-Port durch die DLL immer noch geöffnet.

Danke für eure Hinweise das es wohl an der DLL liegen muss statt an LabVIEW. Hätte da sonst wahrscheinlich noch ewig gesucht .