C programmieren inLabVIEW

Ich bin mir noch nciht sicher, ob es wirklich leichter ist, ein subVI einzufügen oder eine Unterfunktion in c++ aufzurufen. Bei LV muss ich klciken und in der Funktionspalette das richtige VI auswählen, bei C++ schreib ich den Funktionsnamen hin (je na umgebung kann man auch hier mit klicken weiter kommen). Dann müssen noch daten übergeben werden. bei LabVIEW such ich auf der oberfläche das entsprechende element und verdrahte es, bei c++ schreib ich den variablennamen hin (auch klickbar).

Im endefekt muss jeder selbst wissen, was man lieber macht, möglich ist alles, in beiden sprachen. Die eine ist geschickter für das eine und die andere für was anderes. Wer textbasiert aufgewachsen ist, wird c++-code deutlich schneller verstehen können. wer gerne malt ist bei LabVIEW gut aufgehoben. und auch bei LabVIEW muss man sich sehrwohl um die variablendeklaration kümmern, nur anstatt int x zu tippen wählt man eben aus der funktionspalette das entsprechende eingabeelement aus und setzt den datentyp auf int32.

ein großer vorteil den ich bei LabVIEW sehe: man muss keine vokabeln lernen weil man alles durch klicken und die gute kontexthilfe finden kann. wer den begriff INT nicht kennt, wird probleme haben einen entsprecchenden wert in c++ zu deklarieren.

Die diskussion, welche programmiersprache die bessere ist, wird wohl nie enden und nie zu einem ergebnis führen. Einfach dadurch, dass menschen nicht gleich sind, und dass die problemstellungen nicht gleich sind.

aber die idee, c in LabVIEW zu benutzen, weil man c kann und LabVIEW nicht ist meines erachtens nicht diskussionswürdig.

LG
Torsten

Anzeige

' schrieb:Die diskussion, welche programmiersprache die bessere ist, wird wohl nie enden und nie zu einem ergebnis führen. Einfach dadurch, dass menschen nicht gleich sind, und dass die problemstellungen nicht gleich sind.

Stimmt haargenau. Es wird immer Leute geben, die C(++) besser als LabVIEW finden und umgekehrt.

' schrieb:aber die idee, c in LabVIEW zu benutzen, weil man c kann und LabVIEW nicht ist meines erachtens nicht diskussionswürdig.

Auch hier kann ich nur zustimmen! Vor allem, wenn der Kunde eine Lösung in LabVIEW haben will. Und dann kriegt er C-DLLs oder CINs, das kanns doch nicht sein...
Als Auftraggeber würde ich dir das was husten!

Gruß, Jens

Man könnte den Code in einem String speichern, diesen dann in einem makefile speichern, diesen dann vom ohnehin nötigen externen C-Compiler übersetzen lassen und die Ergebnisse wiederum über txt-dateien einlesen!?


definitif machbar

das hier passt doch zu Thema:
Spricht LabVIEW auch C? -> NI.COM

' schrieb:Man könnte den Code in einem String speichern, diesen dann in einem makefile speichern, diesen dann vom ohnehin nötigen externen C-Compiler übersetzen lassen und die Ergebnisse wiederum über txt-dateien einlesen!?
definitif machbar

Aber mal im Ernst, wenn ich die CINs richtig verstanden habe, bist du mit dieser Beschreibung sehr nah an einer CIN.

' schrieb:aber die idee, c in LabVIEW zu benutzen, weil man c kann und LabVIEW nicht ist meines erachtens nicht diskussionswürdig.

Auch hier kann ich nur zustimmen! Vor allem, wenn der Kunde eine Lösung in LabVIEW haben will. Und dann kriegt er C-DLLs oder CINs, das kanns doch nicht sein...
Als Auftraggeber würde ich dir das was husten!

Gruß, Jens

Solche Diskussionen wollte ich mit meiner Frage nicht auslösen.
Es ging hier lediglich darum ob es möglich ist das zu machen! Ich habe, glaube ich, nicht nach der Sinnhaftigkeit einer solchen Aktion gefragt!?
Auch ein Grund war dass wir in der Arbeit bereits bestimmte Standardbausteine haben welche wir schon in den verschiedensten Systemen einsetzen (Siemens, B&R usw. also textbasiertes Programmieren) und ich diese eben auch gerne in LabVIEW einsetzen wollte.
Fakt ist es ist möglich! Mehr wollte ich gar nicht.
Dass das Programm dadurch sehr wahrscheinlich nicht mehr durchschaubar wird davon gehe ich mal aus.
Daher hat sich das mit dem C-Code in LabVIEW einbinden für mich erledigt. Werde mich halt in LabVIEW einlesen müssen und es so machen.

Gruß Robert

' schrieb:Solche Diskussionen wollte ich mit meiner Frage nicht auslösen.
Es ging hier lediglich darum ob es möglich ist das zu machen! Ich habe, glaube ich, nicht nach der Sinnhaftigkeit einer solchen Aktion gefragt!?
Auch ein Grund war dass wir in der Arbeit bereits bestimmte Standardbausteine haben welche wir schon in den verschiedensten Systemen einsetzen (Siemens, B&R usw. also textbasiertes Programmieren) und ich diese eben auch gerne in LabVIEW einsetzen wollte.
Fakt ist es ist möglich! Mehr wollte ich gar nicht.
Dass das Programm dadurch sehr wahrscheinlich nicht mehr durchschaubar wird davon gehe ich mal aus.
Daher hat sich das mit dem C-Code in LabVIEW einbinden für mich erledigt. Werde mich halt in LabVIEW einlesen müssen und es so machen.

Gruß Robert

Um mal wieder ein bißchen Ernst in die Diskussion zu bringen: Natürlich gibt es oft den Fall, das man bereits vorhandene Sourcen nutzen möchte und nicht mehr oder weniger aufwendig in LabVIEW nachprogrammieren möchte. In solchen Fällen sollte man auf DLLs zurück greifen. Das ist natürlich auch nicht die feine Art, besonders wenn der Kunde eine LabVIEW-Lösung wünscht. Dabei stellt sich natürlich die Frage, was der Kunde erwartet!? Braucht er nur eine EXE und aus welchen gründen auch immer möchte er sie mit LabVIEW erstellt haben, oder will er einzelne VIs, an denen er später selbst weiter rumspielen kann!?

Den Weg über die DLLs sollte man dann wählen, wenn man entweder bereits implementierten Code verwenden möchte oder eine andere Programmiersprache wesentliche Vorteile bietet. Zum Beispiel Geschwindigkeit oder ähnliches.

Das Problem war gleube ich einfach nur, dass du von Anfang an gesagt hast, dass du keine fertigen Programme (was für mich auch DLLs einschließt) verwenden willst.

Auch wenn die Diskussopn ein bißchen aus dem Ruder geraten ist, hoffe ich, dass es dich weiter gebracht hat. Und die Idee, dass du dich in LabVIEW einarbeiten willst halte ich nach wie vor für eine gute Sache.

LG,
Torsten

.... und wenn Du Dich dann eingearbeitet hast, willst Du nix anderes mehr.

Gruß Markus

' schrieb:Werde mich halt in LabVIEW einlesen müssen und es so machen.

' schrieb:Keiner wird wohl was anderes als LV nehmen, wenn er eine Messwerterfassung machen muss. Keiner wird was anderes nehmen als C++, wenn er einen Systemtreiber für eine Graphikkarte schreiben soll. Irgendwann wird auch die LV-IDE so weit sein, dass sie so gut ist wie die von Delphi.

Systemtreiber sind oft noch immer in standard C geschrieben. Ist was mühsamer weil man sich da um mehr Dinge selber kümmern muss dann C++ aber das ist oft auch eine Stärke wenn man so nahe am System programmiert.

' schrieb:Ja, so weit ich weiss, ist das im Prinzip möglich, mit den sogenannten Code Interface Node (CIN). Auskennen tu ich mich damit aber nicht. Damit kannst du quasi C-Code einbinden. Soweit ich weiss, brauchst auch noch einen C-Compiler.

Da hast Du etwas falsch begriffen was CINs betrifft. CINs sind im Grunde nicht viel anderes dann DLLs. Du schreibst C Code, compilierst den mit einem Compiler, lässt ein LabVIEW Tool darauf los, das das resultierende Objektfile (unter Windows grundsätzlich eine DLL) in ein anders Format umpackt und lädst das Ganze in die CIN Node. Vorteile zu DLLs: grundsätzlich keine mehr. Nachteile: die Toolchain muss grundsätzlich von LabVIEW unterstützt werden, das CIN wird in ein VI geladen und wenn man dieses VI auf einer anderen Architektur (z.B. Windows -> Unix) lädt ist das eingelagerte binaire File nutzlos und muss manuel durch ein anderes ersetzt werden. Multiplattform VIs sind dadurch eine mühsame Sache.

Wer Englisch kann und eine lange Abhandlung über den Werdegang von CINs und warum man sie heutzutage nicht mehr brauchen sollte, und noch ein paar Tricks um mit DLL's/Shared Libraries eben schon Multiplattform Lösungen zu machen, lesen möchte kann sich ja mal die Texte unter http://expressionflow.com/author/rolfk/ zu Gemüte führen.

Rolf Kalbermatter