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