これは主観的な質問としてマークされていますが、反対票が多すぎないことを願っています。
LV は、従来のテキストベースのプログラミングに代わる優れたグラフィックを提供しているようです。私が理解しているように、それは単なる仮想化/データ取得プログラミング言語ではありません。それにもかかわらず、そのパラダイムは作成者の名前に固定されているようです.
多目的アプリケーションに広く使用されていないように見えるので、私の質問が出てきます。私は LV の専門家ではなく、どちらかというと学習者です。LVに慣れてきました。
Labview は、ナショナル インスツルメンツのハードウェアを使用していて、データの取得、プロット、ログ記録などを行いたい場合に最適です。
カスタム デバイスとのインターフェイスを開始すると、モジュール間の配線が複雑になり、デバイスへの入力と出力のためにすべての文字列操作作業を行う必要があります。
私の職場では、デバイスにインターフェースするために大規模で複雑な VI を作成しなければならないことに悩まされ、.NET でそれらを書き始め、Labview にインターフェースするようになりました。
最終的に、Labview をすべて廃棄し、Visual Studio 用の NI Measurement Studio を使用して、C# の柔軟性を備えた見栄えの良い NI コントロール (波形プロット、タンク、ゲージ、スイッチなど) をすべて提供することになりました。
要約すると、24 インチの画面がいくつかある場合でも、Labview コードの配線が複雑になりすぎて、コメント、デバッグ、および将来の変更に対する拡張が不可能になる場合があります。Visual Studio 用の Measurement Studio とかわいいNIコントロールでお気に入りの.NET言語を使用してください。
「従来のテキストベースのプログラミングに代わるグラフィック」に関する私の 2 つの経験は恐ろしいものでした。そのような言語は使いにくく、編集が難しく、表現力に欠けると思います。それらをデバッグするのは悪夢です。そして、彼らは本当の利点を提供しません.
確かに、私が見たのはかなり前のことですが、私がそれらについて尋ねた他の人の意見は生ぬるいだけだったので、私は二度と見ませんでした. 再検討する理由は大歓迎であり、採用されます...
Labview は、大規模で複雑なソフトウェア プロジェクトのオーサリングに使用できます。Labview は、間違いなく構文ベースの言語よりもはるかに楽しく使用できます。labview を使用して、数学的に緻密で動的なシミュレーションをプログラムしました。Labview の新しいバージョンには、特に複数のプロセッサを利用するための多くのエキサイティングな機能が含まれています。私はLabviewがとても好きです。しかし、私は誰にもお勧めしません。
残念ながら、単純な取得と表示以外では、これは絶対的な悪夢です。いつの日か、テキストベースの言語に代わる実行可能な言語と見なされるように十分に開発される可能性があります。しかし、NI の開発者は一貫して、labview を悩ませている 3 つの基本的な問題を無視することを選択してきました。
1) 不安定で、バグだらけです。labview サポート フォーラムには、まだ修正されていない何千ものバグが投稿されています。これらのいくつかは、メモリ リークや基本関数の数学的エラーなど、非常に深刻なものです。
2) ドキュメンテーションはひどいものです。多くの場合、ローカル ヘルプ ファイルで labview 関数のヘルプを探すと、詳細を見つけようとしているアイテムの名前を単に言い換えている文が見つかります。例: ユーザーがテクスチャ フィルタ モードの設定に関するヘルプ ファイルを参照すると、ヘルプ ファイルに「テクスチャ フィルタ モード - テクスチャ フィルタリングに使用するモードを選択する」と書かれているだけです。ええ、ありがとう。それは物事を正しく片付けますよね？問題はさらに深くなります。多くの場合、ナショナルインスツルメントの技術担当者に labview 機能または数学関数の特定の動作に関する重要な詳細を提供するように依頼すると、彼らは自分のライブラリの関数がどのように機能するかを単純に知りません。これは誇張のように聞こえるかもしれませんが、そうではありません。
3) グラフィカルなコードをきれいに保ち、十分に文書化することは不可能ではありませんが、Labview はこれらのタスクを困難かつ非効率にするように設計されています。コードが絡み合って紛らわしいものにならないようにするために、定期的に (数回の操作ごとに) クラスター、サブ vis および巨大なタイプ定義コントロール (大規模なプロジェクトでは複数の画面にまたがる可能性があります) などの構造を使用する必要があります。これらの構造はメモリを消費し、labview にメモリ内のデータの複数のコピーを強制的に作成させ、無償の操作を実行させることでパフォーマンスを低下させます。これらはすべて、グラフィック ダイアグラムが虹色のスパゲッティのように見えず、コメントやテキストが見えないようにするためです。labview でのプログラミングは、悪魔と戯れるようなものです。あなたの巨大なソフトウェア プロジェクトが、言葉のない壁サイズのフローチャートとして書かれていると想像してみてください。ここで、すべての線が互いに何千回も交差し、データ フローの追跡が完全に不可能になったと想像してください。labview でプログラミングする最も自然で効率的な方法を思いついたところです。
Labviewはクールです。Labview は新しいリリースごとに改善されています。ナショナルインスツルメンツが改良を続ければ、いつの日か汎用プログラミング言語として素晴らしいものになるでしょう。現時点では、大規模または論理的に複雑なプロジェクトのソフトウェア開発プラットフォームとしては、非常に悪い選択です。
私はLabVIEWで20年近く書き続けています。自動テストシステムを開発しています。私は、RF、Vison、高速デジタル、およびさまざまな種類の混合信号テスト システムを開発しました。LabVIEWに切り替える前は、私は「C」プログラマでした。
LabVIEW で一部のプログラムをすばやく構築できることは事実ですが、他の言語と同様に、再利用可能なコードでクリーンで簡単に維持できる大規模なアプリケーションを構築するには、多くのトレーニングが必要です。この 20 年間、LabVIEW のバグによってプロジェクトの完了が妨げられたことは一度もありません。
その昔、NIWEEK では毎年ソフトウェアの銃撃戦が行われていました。LabVIEW と LabWINDOWS (NI の "C" のバージョン) プログラマーは、同じ問題を与えられ、どちらのグループが最初に終了したかを競います。毎年、最初の LabWINDOW 担当者が終了する前に、すべての LabVIEW プログラマが終了しました。私は熱心なテキストベースのプログラミングの友人の多くに銃撃戦を挑んできましたが、たとえ私がソフトウェアの問題を定義させたとしても、彼らは皆チャンスを逃したことを認めています。
ですから、LabVIEW は優れたプログラミング ツールだと思います。あらゆるタイプの NI ハードウェアと接続している場合は、間違いなく最適な方法です。それがすべての答えではありませんが、LabVIEW を「本物のプログラミング言語」と見なしていないという理由だけで、LabVIEW を使用していない人がたくさんいることは確かです。結局のところ、ブロックの束を配線するだけですよね？多くのテキスト ベースのプログラマーが、自分たちだけが理解できる、自分たちだけが作成したテキスト コードの混乱を誇りに思っているため、鼻を鳴らすのはおかしいと思います。どの言語でも優れたプログラマーは、他の人が簡単に読めるコードを作成する必要があります。従うことが不可能な過度に複雑なコードを書いても、そのプログラマーは天才ではありません。これは、プログラマーが「コンパイラー」(単純な問題を取り上げて複雑にすることができる人) であることを意味します。私はキスの原則 (KEEP IT SIMPLE STUPID) を信じています。
とにかく、私の 2 セントの価値があります! **
LabVIEWはFPGAプログラミングの夢だと思っていました。独立した実行可能ブロックはただ... 機能します。一般に、DAQ および FPGA ハードウェアと接続するさまざまなタスクに LabVIEW を使用しますが、それだけです。これが LabVIEW の長所であり、LabVIEW が構築された理由でもあるように思えますが、それ以外では「扱いにくい」と感じます。物事を成し遂げるという点では、学習曲線のある他の言語と同じです。一度理解すれば、仕事を成し遂げるのにそれほど悪くはありません。その前に、学習曲線が永続的か何かだと思ってあきらめる人を何人か見てきました。
30 インチ モニターを購入したことで、大きな違いが生まれました。
人々が嫌うものの 1 つは、バージョン管理の統合です。
編集：LabVIEW/ハードウェアは、「ただの楽しみ」で使用するには非常に高価です。私は彼らのハードウェアに 10,000 ドル (学生価格) を落とし、家でおもちゃを作るためのソフトウェアを学校から無料で入手しました。
当社は過去 10 年間、対象 (列車) の測定、監視、およびレポート作成に LabVIEW を使用しています。
最近、LabVIEW を大量のデータを含むデータベース用の GUI として使用し始めました。最近の新機能 (クラス、XControls) を備えた LabVIEW のパワーにより、他のプラットフォームの開発コストのほんの一部でこれらの種類の GUI を作成することができます。コンサルタント料金で外部プログラマーは必要ありませんが。
トン
私が最初に Labview を使い始めたのは、大学の物理実験室でした。最初は、他のテキストベースの言語に比べて遅くて扱いにくいと思っていました。複雑なロジックを作成するのは難しすぎて、コードはすぐにずさんなものになりました (どこにでも配線がありました)。
それから数年後、サブ vi とバンドルの使用について学びました。なんという違いでしょう！この時点で、私は非常に高レベルの機能に labview を使用していました。私はカメラから生の入力を取得し、あらゆる種類の画像フィルターと処理を使用して最終的に道路の線を解析し、車両がドライバーなしでこの道路を自動運転できるようにしました。それは DARPA URBAN CHALLENGE のためでした。また、テキストのウェイポイント データからマップを生成したり、高レベルの解析関数を作成したり、入力デバイスからのデータの処理とは関係のない多数のアプリケーションを作成したりしていました。とても楽しかったです。そして速い。
大学を卒業した後、私はテキストベースの言語を使用するようになりました。私が使用してきたもの: PHP、Javascript、VBA、C#、VBscript、VB.net、Matlab、Epson RC+、Codeigniter、さまざまな API、そして他にもいくつかあると確信しています。かなりの速度でプログラミングするために覚えなければならない構文の量に、私はよくイライラします。使用している言語に基づいて考え方を変えなければならないのは面倒です...すべてのプログラミング言語が本質的に同じことをするのに! 同じ関数の構文を異なる言語で見つけることができるように、常にヘルプを表示するためだけに 2 つ目のモニターが必要です。私は Labview がとても恋しいです。それはとても高価なので、それ以外の場合はすべてに使用します。
グラフィックベースのプログラミングには大きな可能性があると思います。構文に制約されないことで、コードではなくロジックに集中できます。Labview 自体は、サポートとデバッグに関してはまだ初期段階にあるかもしれませんが、概念的には競合他社に勝っていると思います。シンプルで直感的なプログラミング方法です。
エンドオブラインテスト機器の実行にはLabVIEWを使用しており、データの取得と制御に最適です。通常、15〜80の差動電圧を測定し、環境チャンバー、マスフローコントローラ、およびさまざまなシリアルデバイスを制御するLabVIEWは、十分な能力を備えています。
カスタムデバイスとのインターフェイスは、NI計測器ドライバウィザードを使用して再利用可能なVIを作成し、必要に応じてカスタムdllとインターフェイスすることで大幅に簡素化できます。多くのプロジェクトで、カスタムハードウェア用のそのようなドライバーを作成しました。作成すると、変更なしで将来のプロジェクトで再利用できます。
イベントドリブン構造を使用すると、ユーザーインターフェイスは応答性が高く、LabVIEWアプリケーションを定期的に使用してデータベースとインターフェイスします。
どのプログラミング環境を選択する場合でも、最も重要なのはアプリケーションを設計するプロセスです。LabVIEWで非常に恐ろしくて読めないブロック図を作成できることに同意しますが、VisualStudioで読めないコードを作成することもできます。少し考えて計画するだけで、LabVIEWのブロックダイアグラムを、コメントを追加するための十分なスペースがある単一の24インチモニターに収まるように作成できます。
ほとんどのプロジェクトでは、VisualStudioではなくLabVIEWを使用します。
しかし、人々は LabView をデータ取得と仮想化以外の目的で使用しています。もちろん、LabVIEW は NI の主要な顧客ターゲットの 1 つである (またはあった) ため、主にラボや生産環境で使用されます。
ただし、多くの画像解析を実行するロボットをプログラミングし、結果をツイートするなど、LabVIEW を使用してさまざまなことを行うことができます。you-tube で NI Week 2009 のビデオを見ると、このツールがいかに強力であるかがわかります。たとえば、コードを記述して ARM MCU に展開する可能性があります ( 2009.08.10 のDev Monkey の記事を参照してください)。
そして最後に、このLabVIEW DIYグループをチェックしてください
私はこの問題について何十年も考えてきました (そう、1989 年以来...)。
すべてのプログラミング言語と同様に、LabVIEW は電子の流れを操作するために使用される高度なツールです。あなたが純粋主義者で、ブレッドボードとワイヤー以外のものを使用することを拒否しない限り。何か重要なものを構築したいのであれば、トランジスタ、集積回路、プログラミング言語はおそらく良いことです。
しかし、すべての高度なツールと同様に、それを使用するだけでプロの職人になることはできません。はんだごて、オペアンプ、UART の時代には、実際に機能するシステムを作成する前に、かなりの注意深い研究が必要でした。現代のテキストベース言語の領域は、構文に過度に支配されているため、プログラマーは、コンパイルして実行する前に構文を理解する必要があります。機能するコードを作成するには、プログラマーはスキル レベルを上げて、"Hello World" よりもはるかに大きなシステムを作成する必要があります。
LabVIEW は構文ではなく、データフローに支配されています。昔は、フローチャートのテンプレートに手を伸ばし、バランスの取れた情報システムの図を作成することが、仕事の芸術と美の部分でした。レビュー済みのフローチャートを手元に置いて初めて、コードを打ち抜くという単調な作業に苦労することさえ考えるようになります。（はい...パンチカード）
LabVIEWは、プログラマがフローチャートツールを使用して完全な情報システムを図化し、「実行」を押すことを可能にする開発システムです.LabVIEWは「コードを打ち抜き」、それをコンパイルします。テキスト言語 A や言語 B の構文に苦労する必要はありません。
このような強力なツールを使用すると、初心者でも大規模な作業プログラムをすばやく構築できます。これは、実際に実行されるため、ある程度のプロの職人技を意味します。ただし、システムが適切に動作しない場合やソースコード図がごちゃごちゃしている場合、それは LabVIEW のせいではありません。
「LabVIEW は、大規模なデータ収集システムの開発にのみ適している」とよく指摘されます。おそらく、それらの人々は、データ取得に取り組んでいる科学者やエンジニアのプロフェッショナリズムを考慮する必要があります. 彼らがセンサーとトランスデューサに適切な実際のワイヤを取得するのに十分な知識がある場合は、LabVIEW 配線図の作成にも精通しているはずです。
自動化の開発にLabVIEWを約2年間使用しています。十分な注意と適切な設計を行えば、LabVIEWで保守可能で非常に見栄えの良いアプリケーションを開発できるはずです。これは他のすべての言語でも同じだと思います。LabVIEWで同様に悪いコードを見たのは、主に、迅速で汚い自動化を開発するためだけにそれを使用する人々からです。IMHOグラフィカルプログラミングは、正しく実行されれば、コーディングと理解がはるかに簡単になります。しかし、それは私がテキストベースのプログラミングを「感じ」より強力だと感じていると言った！LabVIEWは主に産業用自動化のために販売されており、多くのNIハードウェアを固有にサポートしており、サードパーティのハードウェアを非常に迅速に動作させることができます。それが自動化の分野でしか見られない理由だと思います。
LabView は自動化分野でのみ訴えられていると誰かが言いました。まったく書かないだけです。デジタル信号処理、制御システム、通信、Web ベース、数学、画像処理などのアプリケーションがあります。それはデータ取得方法として始まり、彼らは Virtual Instrumentation という名前を発明しましたが、今ではそれをはるかに超えています。これは、比類のないグラフィカル インターフェイスを備えた科学的プログラミング言語です。これは Simulink をはるかに超えており、Matlab が好きな場合は、そのようなプログラミング方法が好きな人のために、Matlab スクリプトが組み込まれています。それは常に進化しています。私が難しかったことの 1 つは、Compact Rio のコードを書くことでした。トリッキーですが、他の方法よりもはるかに簡単です。高価ですが、高品質の製品を手に入れることができます。個人的には、通常のプログラミングでバグを発見したことはありません。
私は LabView を約 10 年間使用しています。これは、Matlab や Simulink などの科学的プログラミングには優れていますが、10 倍優れています。問題がある場合は、何か間違ったことをしています。他の言語と同じように習得には時間がかかります。代わりに.Netを使用することについて-これらの人々は同じ惑星にいますか? FFTなどをプルアップして、すでに書かれたコードを使用できると言うことができるのに、なぜゼロからすべてを書くのに苦労するのでしょうか。.NET は単純なプログラムには適していますが、科学的な処理にはあまり適していません。はい、できますが、グラフィックスなどのアドオンがたくさんあるわけではありません。もちろん、インターフェースを使用してdllを使用している場合は、cでプログラムできます。現在、LabView を使用しないことがいくつかあります。たとえば、音声認識は、現時点では少し面倒かもしれません。さらに重要なことは、簡単な代替手段があるのに、なぜ人々は時代遅れのテキスト形式でプログラミングを好むのでしょうか。人は自分の仕事を何らかの形で正当化するために物事を複雑にしたいと思っているようです。簡素化 簡素化！
息子が大好きなレゴ マインドストームの一部であるLabViewを自宅で使用しています。そして、このようなシステムを構成する方法が本当に好きです。
ただし、私の仕事 (組み込みシステム) では、一般的に制限が厳しいです。しかし、ここでも抽象化を進めようとしています: - 制御と状態の動作: モデル ベースの設計 (すなわち Rhapsody) - データ アルゴリズムなど
グラフィカル モデルでは、コードよりも多くのクリックが必要になる場合があります。しかし、これには優れたプログラマーが設計とドキュメンテーションで行う必要がある作業も含まれます。コードのタイピングだけではありません。グラフィカルな表記法は多くの手間を省き、ツールが目の前の複雑さに対して十分に強力である場合、一般的にはるかに高速です。したがって、これらの種類のツールが成熟し、人々がそれに慣れるにつれて、今後数年間でこれらの種類のツールの人気が高まると予想しています。