Hardwareprotokoll (.Net C#) einbinden

Hallo,

bei mir liegt folgende Situation vor: Ich habe eine Hardware welche mit einer eigenständigen Software über ein Protokoll welches in C# geschrieben ist kommuniziert. Die Hardware ist über Ethernet an den PC angeschlossen. Die eigenständige Software möchte ich nun durch LabVIEW ersetzten, d.h. das Protokoll (dll-Dateien) muss zur Kommunikation mit der Hardware in LabVIEW eingebunden werden.

Meine Fragen dazu sind:

Ist das prinzipiell möglich?

Wie ist es mit eigenen Threads die in der DLL-Datei gestartet werden?

Wie schaut es mit Exceptions aus? Machen diese Probleme?

Ich habe mich schon ein wenig mit dem Thema befasst und Test mit Konstruktorknoten, Methodenknoten und Eigenschaftknoten gemacht jedoch bin ich noch nicht so weit gekommen. Vielleicht kann mir jemand von euch helfen der schon Erfahrung mit solchen Themen Gemacht hat.

Vielen Dank schon mal für die Anworten

Anzeige

Du schreibst zwar etwas von DLL, aber im Prinzip scheint das alles ganz einfach .Net zu sein.

Machbar ist das sicher, eigene Threads innerhalb der .Net Komponente sollten auch keine Mühe machen so sie denn gut programmiert sind und keine Zugriffskollisionen mit dem .Net Interface das Du von LabVIEW aus aufrufst machen können. Exceptions soweit sie im Zugriffsinterface nach LabVIEW auftreten werden ganz einfach als Fehler in die LabVIEW error Cluster eingefügt, Exceptions innerhalb der externen Threads werden je nach spezifischer Implementation verarbeitet. Ohne spezielle Vorrichtungen, um die zum LabVIEW Interface hin zu kommunizieren, werden die in LabVIEW selber nicht sichtbar.

Eine andere Variante, sofern das TCP/IP Protokoll bekannt ist, wäre die komplete Implementation dieses Protokolls ganz in LabVIEW. Das ist zwar etwas Arbeit, aber je nach Komplexität des .Net Interfaces und des Protokolls könnte das durchause interessant sein.

Rolf Kalbermatter

Vielen Dank für die schnelle Antwort.

Das mit der kompletten implementation in LabVIEW hab ich mir auch schon überlegt aber das Protokoll ist so komplex dass es keinen Sinn macht es so zu machen.

Die einzelnen Methoden kann ich doch dann über Methodenknoten aufrufen oder?
Und die Eigenschaften mit .Net Eigenschaftsknoten?

Eine andere Überlegung von mir war noch eine Wrapper-DLL zu schreiben um die Probleme zu lösen. Meinst du das macht mehr Sinn? Oder denkst du das es auch so funktioniert?

MFG

Schönen guten Morgen

IMHO ist ein Wrapper nicht die schlechteste aller Lösungen.
Ich habe auch schon einiges mit .NET/C# gemacht und für mich war und ist ein Wrapper eindeutig die bessere Lösung.
Du musst zwar mehr Code verwalten, aber dein Code bleibt übersichtlicher. C# in LabVIEW komplett ausprogrammieren finde ich sehr unübersichtlich. Auch mit StateMachines usw...Und durch einen Wrapper kannst du dir nur die notwendigen Methoden (Init/DoStuff/Exit) nach "aussen" führen. So ist der C# Code lesbar und LabVIEW auch.

Gruss,
Christian

' schrieb:Die einzelnen Methoden kann ich doch dann über Methodenknoten aufrufen oder?
Und die Eigenschaften mit .Net Eigenschaftsknoten?

Ja, ist doch verwunderlich dass diese Dinge im Namen so genau übereinstimmen!

Zitat:Eine andere Überlegung von mir war noch eine Wrapper-DLL zu schreiben um die Probleme zu lösen. Meinst du das macht mehr Sinn? Oder denkst du das es auch so funktioniert?

Ausser wenn das .Net Interface super-spezielle Dinge tut, die in der einen oder anderen Form durch LabVIEW nicht (gut) unterstützt sind, geht das sicher auch direkt von LabVIEW aus, ohne extra Wrapper. Da ich mich mit C# nicht auskenne würde sich für mich diese Frage auch gar nicht stellen. Ansprechen auch sehr komplexer .Net Interfaces direkt aus LabVIEW würde für mich fast immer einfacher sein als einen C# Wrapper zu schreiben, der das Ganze in ein einfacheres Interface umsetzt.

Bei mir wäre eine .Net Lösung ohnehin immer die letzte Lösung die ich wählen würde, ausser vielleicht ActiveX, das hat noch weniger Popularität bei mir. .Net scheint zwar manchmal der Alleszugleichtöter für alle möglichen Probleme, aber man handelt sich damit auch eine flinke extra Komplexität ein, die zwar in vielen Fällen geschickt under der Haube von .Net versteckt wurde, aber wenns den mal wirklich kritisch wird, dann ist die Büchse von Pandora noch ein angenehmes Geschenkpäckchen im Vergleich.

Rolf Kalbermatter