よく頂く御相談に「前任者によるソースコードがあるものの、全体構成が理解できず改修できない」という案件があります。
御存知の通りLabVIEWは「グラフィカルプログラミング言語」ですので、作り方を間違えたり、無法でプログラムを作り込んでいくと、可読性の低いプログラムができてしまっているケースがございます。この場合、「どこから、どう動いているのかわからない」と感じる方が多いようなので、どこから追跡すべきか？に絞っていくつかポイントを記します。
- ローカル /グローバル変数が多数、分散して使われているケース
ローカル/グローバル変数は実行順序の制御ができず、かつ分散/並列して利用されてしまうと、追跡が非常に困難になるケースがあります(特に仕様が明確でない場合)。この場合は、制御器/表示器orローカル変数上で右クリック、「検索→ローカル変数」で「書き込みされている場所」を追跡してください。
多くのケースでは「書き込み＜＜読み込み」で用いられているため、書き込まれた場所を特定することで、起点を探すことが可能となります。 - エラーが発生し、エラーダイアログが表示されてしまうケース
エラーワイヤが正しく配線されていない場合、オプション設定でエラー制御が意図しない設定になっている場合に見られます。エラーダイアログを設置していないのにも関わらず、エラーダイアログが表示され動きが阻害される、などが該当します。
まずはエラーが発生しているvi名をエラーダイアログから特定します。次に、そのviを開き、エラーオプションを確認して、自動でエラーダイアログが表示されるようになっているか？を確認してください。LabVIEWではエラー処理がAutoになっている場合、そのサブviのエラー端子が上位側で「配線されていない場合」、自動的にエラーダイアログが「表示されてしまう」迷惑な仕様になっています。ですので不必要にエラーダイアログが表示される場合には、上位側でエラーワイヤを適切に処置するか、サブvi側でauto detectをoffすることでエラーダイアログを抑制することが可能です。本来エラーワイヤは極力配線することが基本ですが… - ブロックダイアグラムが広大で追跡が困難なケース
GUIプログラムなので、工夫しないと画面上にパーツが散乱してしまい、機能拡張をするごとに面積が広大になる傾向があります。このようなプログラムに遭遇した場合、まずはモニタ画面内に収められないか？を検討してください。モニタ画面から外れる大きさの場合、思考が妨げられて追跡が困難になるように感じています。まずはサイズを小さくする、を行いましょう。
次に、同じ機能を繰り返し行っている箇所、ブラックボックス的に利用しても問題ない部分をサブvi化できないか？を検討してください。サブvi化してそのviを使うことで、画面占有面積の低下、サブvi単体でのデバッグ実行、などが可能となります。それと画面が広大なソースの場合、上下/左右へｎスクロールは避けるよう修正することが重要です。ワイヤフロー的にスクロールする場合、左右へのスクロールは許容、上下スクロールはNG、などのルールを決めることで可読性が向上すると思います。 - 実行順序が明確でなく追跡困難な場合
並列ループなどで追跡困難なケースの場合、デバッグ機能を活用することをお勧めします。各並列ループのトリガとなる起点をまず見つけ出し、そのトリガ発生後の位置にブレークポイントを仕掛けます。その状態でＵＩ操作などのイベントを生成し、どの順番にブレークポイントで停止するか？を追うことで凡その流れが把握可能です。ある程度流れを掴んだ後は、デバッグ用のサブviなどを作成し、各所にそれを埋め込むことで実行された時刻、順番などのログをデバッグviの中に保存します。プログラム実行後、その実行履歴から、どのviがどういう順序で実行されたのか？などを確認することが可能です。 - パフォーマンスの低下が大きい場合
私見ですが、プログラムを作成し動作させた場合、実行するPC負荷率が30%を超えるようなプログラムの作り方は問題だ、と考えています(RealtimeOSのプログラムを除く)。特にWindowsなどの場合ジッタは数ms～1000msなど幅が広くなることがあり、注意が必要です。LabVIEWのツールにあるパフォーマンスモニタなどでどのviの実行回数が多いのか？メモリを大量消費しているviはないか？などを確認することで、トラブルを発生している場所をある程度推測することが可能です。特に大きい文字列をメモリで使いまわしている場合、表示器/制御器の改行演算が毎回行われる場合があり、極端に速度低下する場合が多く見られますので注意が必要です。
その他、色々と対応方法はありますが、また機会を見て記載させて頂きます。