自動計測技術フォーラム(大阪)を聴講した

公私多忙の日々で、せっかく立ち上げたこのブログが凍結状態。久しぶりにポストしてみよう。

4月23日午後に梅田スカイビルで開催されたNI主催セミナー、自動計測技術フォーラムに参加してきた。計測分野も年々変化していくので、時々展示会などに参加して潮流をつかむことが重要。といっても、東京での開催になると参加費無料といってもさすがに出張は難しいので、関西での開催は助かる。当日は晴れたものの、風が強くて花粉症のぼくには少々つらかった。
参加者は170名程度。NIとしてはNI TestStand製品を中心にアピールして製造関係にフォーカスをあてたかったようだが、講演者の話ではR&D関係者が多かったみたい。というぼくも、R&D部門だけど。
製造業現場の実例を知ることは難しいので、こういうフォーラムでの事例発表から「垣間見る」。もちろん企業秘密は明かしてもらえないけど、改善の方向性は見えてくるし、なにより他社事例を知ることは自分の研究開発の励みになる。

気になったポイント（自分用のメモみたいな話）

  1. 日本NIの池田社長の基調講演は、もちろん一般的な話であったのだけど、なかなか参考になった。最近、「日経ものづくり」を読んでいなかったので、引用されていた統計資料は一度確認してみたい。新興国市場では「低価格、ほどほどの品質」という認識だったけど、新興国市場でも機能が少なくても「高品質」は求められているとのこと。
  2. ぼくは日ごろ、LabVIEWで実行ファイル形式のソフトウエアを作成して社内で配布している。今回の講演では、実行ファイル形式ではなく、NI TestStandを使って現場に配布する方法が紹介されていた。NI TestStandはLabVIEWの上層に置くマクロ・シーケンスのようなもので、LabVIEWソフトウエアは(実行ファイル形式ではなく)開発形式(*.viファイル)としておく必要がある。つまり、NI TestStandを使うと、実行サイトごとにNI TestStandとLabVIEWのライセンスが必要になる。ライセンス料はけっこうかさむことになるが、シーケンスの変更を柔軟に行えるからコストは下がるのだそうだ。
  3. ぼくはこれまでNI TestStandに興味がなかったのだけれど、この提案には考えさせられた。ぼくの経験的にも、研究段階でのLabVIEWの威力は絶大で、これ無しでの研究開発はあり得ないと思っている。しかし、研究段階の結果を製造現場に持って行くのに大きなハードルが沢山ある。そのなかでも、製造現場でのシーケンスの変更やイレギュラー対応するようなプログラムを書く時間が結構かかるのだ。なるほど、NI TestStandを使って、そのプログラミング時間を短縮することは意味がありそうだ。
  4. もっとも、NI TestStandが得意とする分野は、いくらか限られるように思う。今回のフォーラムで中心的に挙げられた、ＰＣや携帯電話、自動車などシステム製品のテストではかなり有効だと思う。一方で、デバイスよりの開発では、NI TestStandの機能の多くは活かされないと思う。むしろ、リアルタイムやFPGAの利用が重要ではないだろうか。もっとも、講演されたペリテックさんは、ICテスタという全くデバイス向け製品を、NI TestStandで組んでいるらしいので、ここはぼくの直感とはずいぶん違うところ。この感覚の違いは、どこから来るのか、そのうち考えてみたい。
  5. デンソーウェーブさんはQRコードで有名な会社。QRコードはほとんどふれずに、FA機器の紹介をしていた。PXIでセンサを使うようなシステムであれば、Gコードで動くロボットは実に魅力的。いつかやってみたいなぁ。
  6. 山口NF電子の発表は、多くの技術者の参考になる内容。とくに担当者にとって。

つまるところ

池田社長の基調講演にあった「組織生産性」を日本の製造業としてどのように向上させるのか、ものづくりの自動化と向き合う技術者は、それに対してどのようなアンサーを出していくべきなのか、といったあたりを考えさせられる半日でありました。単純に自動化するだけでは、ものづくりにはつながりそうにはありません。ものづくりに携わるわれわれ技術者が、限られた時間とリソースの中で、どのようにLabVIEWを活用すれば「ものづくりの神様」とより意味のある対話ができるようになるのか。国際競争に勝ち続けることができるのか。
苦しみの日々は続くなぁ。

DAQmx のCPU使用率が変わったのかな？

DAQmxを連続収録で使うときに問題になるのがCPU使用率。連続収録にしているだけでCPU使用率が100%になってしまう。実際は待ち動作をしているようで、スレッドを占有しているわけではないのだけど、いっけんターゲットPCに余裕があるのかないのかも分からない。困った仕様だった。DAQmxでCPU使用率が高くなることは以前よりNIからアナウンスがあった。
NI-DAQmx および従来型 NI-DAQ（レガシー）に関するFAQ - National Instruments
DAQプログラムの実行時に多量のCPUを消費します - National Instruments
NI-DAQmxを使用したプログラムでCPUの使用率が100%になります - National Instruments
仕方がないのでこれまでDAQmxでAI連続読み取りするときは、読み取りの直前に待機関数(Wait/ms)を自分で追加して使っていた。具体的には「DAQmx 読み取りのプロパティ」→AvailSampPerChan(チャンネル毎の有効なサンプル数プロパティ)を読み取って、読み取りサイズ（この場合20,000）からの差分（つまりこれから取得するサンプル数）をmsに直したものを待機関数に代入していた。下のVIスニペットにAI連続読み取りのループ部分だけを示す（オリジナルのpng画像はクリックして取り出してください）。

この例ではおおむねバッファが読み取りサイズになってから読み取っているので、ループに入る前に十分なバッファ確保（読み取りサイズの倍以上）をしておく。この待機関数の効果はてきめんで確実にCPU使用率が下がる。ループ中に「次のミリ秒倍数まで待機」を配置するよりループ動作が安定する。ぼくの愛用コードだ。

が、アップグレードしたDAQmx 8.9.5を使っていたら、こんな面倒な待機関数を入れなくてもCPU使用率は十分に低くなることを発見した。あれれ、いつの間に仕様変更？うーん、ぼくの愛用コードがまた一つ過去のものに。

最近だと思うけど、アナウンスはあったのかなぁ？ここはやっかいな仕様だったので、改善されたようですね。

マイプロジェクト：ギターチューナーをLabVIEWで (1)

自宅用マイLabVIEWを手に入れて、何か自宅プロジェクトを始めたいと思いつつ、仕事では無くてはならないLabVIEWもぼくの日常では無力*1。小学校に上がる前の娘たちにも、まだ必要なさそうだ。娘の相手をする時間が欲しいし、派手な工作は家でやりにくい。なんて思いつつ、Make: Technology on Your Time Volume 04 や Make: Technology on Your Time Volume 06を読んでいたら、実にアナログな自作楽器たちが紹介されている。もちろん、ギターなんか音程が合うわけがないから記事の中でも市販のチューナーを使って調弦（調音）しているんだけど。ふと思いついた。

「ああ、これだ。LabVIEWにぴったりなアプリ。楽器用チューナー。」

ぼくがLabVIEWに惹かれる理由のひとつは強力なDSP機能やフーリエ変換などの波形処理機能だ。自分ではとてもプログラムできない解析機能が標準でついてくる。サウンド解析はLabVIEWに向いたアプリケーションじゃないか。現在のＰＣの能力を持ってすればチューナーは十分に可能。音声帯域でも中域までで十分だから回路も簡単だし、ＰＣのサウンドボードでも問題ないだろう。

とはいえ、LabVIEWにぴったりすぎるこの分野。日本語でググッてみるとやはり先人はある。

大御所 平林氏の記事もあるのにあえて始めるのは恥ずかしくもある。でも、ぼくの力量に見合うもを作っていくよ。今回のプロジェクトの方針としては、

を特徴に進めてみたい。LabVIEWを知らない人にそのパワーを伝えたい、というのが最大の動機。裏の動機としては、ぼくのプログラミング技術向上の練習台にしたいのだ。実のところ、ぼくが仕事で作っているLabVIEWソフトウエアは役には立つのだけど、非常に深い階層構造でかつ関数の機能が不明確という美しくない代物なのだ。企業で働くものとしては、組織で成果を上げる力を付けたい。すなわち、他の人から可読性の高いプログラムを書く能力を付けたいと思っている。ソースを公開しながら進めるこのプロジェクトにはそんなチャレンジもある。

音楽の勉強もできるし楽しそう。ちなみに、ぼくは市販のチューナーも持っていますよ。持っているなら必要ないよね。でも、自分で作ってみたいんだよ。中が知りたいんだ。

今日はとりあえず、「はじめるぞ宣言」まで。

*1:バージョンが上がれば改善されるかも。→LabVIEW Future Version 77 - YouTube。100年先じゃ生きてないな。

LabVIEWから他のプログラムを起動する

VIスニペット

せっかくLabVIEW2009を使うのでVIスニペット機能の実験がてら、このエントリを書こう。

スニペット（snippet）とは聞き慣れないけど、「切れ端、断片、スクラップ、短い抜粋」の意味らしい。プログラミングでは、よく使う短いコードを登録するような考えのようだ。LabVIEWのコード*1でもこのスニペット機能が搭載された。初めて見たときは驚いた。VIから切り取ったLabVIEWのVIスニペットは、PNG画像になっていて実にビジュアルだ。PNG画像のスニペットをブロックダイアグラム上にドロップすると、あたかも画像を貼り付けたようにコードが現れる。もちろん、これは画像ではなくて動くコード。PNG画像には画像に付加情報をいろいろ仕込むことができるのだけど、VIスニペットは画像情報と同時にコードも内包している。PNG画像の仕様には、公開する必要のないセクション（プライベート チャンク、private chunk）があるので、ここをNIが利用しているのだろう。

VIスニペットのチュートリアルがある。音声の無い動画とサンプル「VIスニペット」も付属。

VIスニペットで再利用を促進 - National Instruments

LabVIEW2009のヘルプファイルには、「VIスニペット」と「コードスニペット」の２種類の言い方が混在。重要な注意書きを見つけた。

LabVIEWはサブVIを.pngファイルに組み込みません。ユーザが.pngファイルをブロックダイアグラムにドロップする際に、VIスニペットで呼び出されたサブVIがコンピュータに存在している必要があります。そうでない場合、VIスニペットには壊れたコードが含まれます。

サブVIで階層化したプログラムをVIスニペットにするときは要注意。自分の環境で使う分にはまったく問題ないんだろうけど、他の人と共有するときは.vi や .llb も検討すべきということだね。このダイアリでも浅い階層で表現できそうなコードはなるべくVIスニペットを使って公開してみようと思う。添付ファイルだけより、ダイアリとしてのインパクトもありそうだからね。

LabVIEWから他のプログラムを起動する方法

これは Solved: LabVIEWでWindowsソフトを起動する - NI Community - National Instruments で勉強させていただいたこと。LabVIEWから他のWindows実行ファイルを起動させるVIはベースパッケージにも含まれる標準機能であるのだけど、あまり使わない機能なのでメニューの場所は忘れやすい。関数は「コネクティビティVIおよび関数→ライブラリ&実行可能ファイルVIおよび関数→システム実行 (VI) 」。このVIはWindowsの cmd プロセスを呼び出す。当然、仕様はWindows の cmd に準じている、といってもDOSを知らない若いユーザはよく分からないかも。

もっとも簡単な例で、Windowsの電卓を起動してみる。

↑これがVIスニペットのサムネイル。画像をクリックして新しいウィンドウが開いたら画像下部の「オリジナルサイズを表示」をクリックするとVIスニペット画像が表示される。*2 *3 LabVIEW2009をお持ちの方は、VIのブロックダイアグラム上にVIスニペット画像をブラウザからマウスでドラッグ＆ドロップするとインポートできるはず。Google Chromeでは直接のドラッグ＆ドロップは上手くいかないので、いったんPNGファイルをディスクに保存してから保存したファイルのアイコンをブロックダイアグラムにドロップすると良い。

コマンドラインの入力文字列はWindowsの「スタート」にある「ファイル名を指定して実行」と同じ機能なので、「ファイル名を指定して実行」で可能なことはここでも可能。「calc.exe」としたが「calc」でも同じ結果になる。このviは「終了まで待機」をTrueにしておくと、電卓を終了するまで次の処理を実行しない。

次に、LabVIEWの設定ファイルをWindowsのメモ帳で開けてみよう。これはNIのサンプル「Calling System Exec.vi」に同じものがある。

コマンドラインに「notepad LabVIEW.ini」と打つだけでは動作しない。パラメータであるLabVIEW.iniへはフルパスが必要だ。コマンドラインを「notepad C:\Program Files\National Instruments\LabVIEW 2009\LabVIEW.ini」としても良いが、ここではデフォルトディレクトリ定数を使って、作業ディレクトリにLabVIEW.iniへのパスを入力している。

ここまではWindowsの環境変数パス上にあるソフトウエアの場合だ。たとえば、電卓→calc、メモ帳→notepad、ペイント→mspaint、マインスイーパ→winmine、MS-EXCEL→excelあたりなら、コマンドラインに実行ファイル名を文字列で入れるだけでよい。Windowsの環境変数パス上にないソフトウエアでは一工夫が必要。ここではNI-MAXを例に取る。

ファイルパスのワイヤを「パスを文字列に変換」関数をつかって文字列に変換すればOK。こういうのは知っていると何でも無いのだけど、はまると辛い。そんなコードをここで紹介していきたいと思っている。

*1:「Ｇ言語」て言うんだよ、知ってるかい

*2:はてなの仕様上、直接クリックでオリジナル画像が開かないのはたいへん残念だ。要望はこちら>>http://i.hatena.ne.jp/idea/23249

*3:はてなfotolife でのVIスニペットアップロードのTips。アップロード時に【□オリジナルサイズの画像を保存】をチェックするのを忘れないこと。【画像サイズxxxピクセル(長辺)】がこの指定値を下回る小さなVIスニペットの場合、一見画像サイズが変更されていない画像がアップロードできるが、これはコード情報が削除されている。小さなサイズのVIスニペットをアップロードするときは、必ずサムネイルが作成されるように、サイズ(xxx)をオリジナルよりも小さく指定してやると、うまくVIスニペットをアップロードできる。

メジャーバージョンアップへの迷い

LabVIEW のリリース履歴をWikipedia（英語版）で見てみる。

Name/Version Build Number Date
LabView 1.0 (for Macintosh) ?? 1986
LabView 2.0 ?? 1990
LabView (for Sun & Windows) ?? 1992
LabView (Multiplatform) ?? 1993
LabView 4.0 ?? 1997
LabView 5.0 ?? 1998
LabView Real-Time ?? 1999
LabView 6i ?? 2000
LabView 7 Express ?? 2003
LabView 8 ?? 2005
LabView 8.5 ?? 2/19/2008
LabVIEW 8.6 8.6.0.4001 7/24/2008
LabVIEW 2009 (32 and 64-bit) 9.0.0.4022 8/4/2009

今年からLabVIEWは西暦でバージョンを示すようになった。製品名を西暦で示すのは、MS-Officeしかり、ATOKしかりでマーケティング上の理由なんだろうけど、ユーザとしては互換性が分かりにくくなるのであまりうれしくない。しかしこの表で分かるように、ビルド番号を追うとLabVIEW2009は、バージョン９になっている。つまり、LabVIEW2009はメジャーバージョンアップなんだね。

世の中には無条件に「新しいものは良いものだ」という広告に踊らされているだけの人もいるけども、現実はそうでもない。Windowsも3.0はひどかった。3.1で使えるようになった。Windows95よりは98が良かったし、MS-Officeはちょっと古い2002か2003がもっともよく使われている。F1やラリーカーだって、新しいマシンを投入したときから圧勝なんてことはなくて、次のシーズンぐらいからチューニングが上手くいって調子が出てくるものだ。

これまでも、LabVIEWのメジャーバージョンアップには、新しい機能に喜ぶ反面、互換性に泣く場面も多かった。
よくあるのは依存性が上手く引き継げないケース。自分では明示していないのにバージョン依存性のあるサブviを使っているときに起きるようだ。大きなプロジェクトをバージョンアップすると、あちこちで競合やらパスの行方不明が起きる（あまり聞かないトラブルだけど、ぼくだけなのか？何か書き方がおかしいのだろうか？）。LabVIEW 7 Express のときには128bitのTIME形式が登場して、波形関数のt0がそれまでDBLだったのがTIMEに変わった。ぼくは波形演算を当時多くしていたので、t0がらみのアルゴリズムが一気にバグ発生源になった。
最近のバージョンでは大きなトラブルは減ってきたようには思うけど、それでもメジャーバージョンアップにはためらいがある。LabVIEW 2009が実質バージョン9だと知ったときは、しばらく見送ろうと考えていた。仕事では安定して使えていることが何より重要だからね。今までのLabVIEWでどのバージョンが好きかと聞かれれば、6.1 と8.6.1 だと答えるよ。

そんな迷いも自分用のLabVIEWが手に入ってしまったことで吹っ切れて、ぼくはLabVIEW 2009へのメジャーバージョンアップと格闘中だ。


今回のメジャーバージョンアップで気がついたこと、

  • 競合で困ることは少ない（たまにある）。
  • 8.6との互換性はよく考えられているようだ（バージョンアップ専用のviとかが現れる）。
  • よく分からない依存性がやはりプロジェクト上に現れる。こういうのをみると全部新バージョン上で書き直したくなる衝動に駆られる。
  • 新機能はまだ使っていないけど楽しみだ。3Dグラフとスニペットは面白そう。
  • ワケの分からないバグに遭遇すると、LabVIEWの新しいコンパイラが原因ではないかと疑ってしまい、いつもより疲れる。

今回のバージョンアップで困ったことの筆頭は実行用ランタイムが巨大なこと。たぶん、8.6のときの倍以上あって、DAQを含まない小さなプログラムでも配布用にすると120MBを超えてしまう。これじゃあ、容易に配布できないよ。機能追加で仕方がないとはいえ、何とかならないのかなぁ。

              • -

そういえば、最近のバージョンでは古いサンプルコードが開けないことが多くて困ったので、ちょっと調べてみたよ。

How to Upgrade or Revert a VI to a Different Version of LabVIEW
【VIをLabVIEWの異なるバージョンにアップグレードまたは戻す方法】 (Japaneseを選ぶと日本語もあるけど、表が古い。)

現在のLabVIEWは、バージョン6以降のファイルは開くことができる。それ以前のバージョンのファイルは、いったんLabVIEW8.2で開いて保存してから開くといいみたい。LabVIEW3以前のファイルに遭遇することはたぶん無いからこれで大丈夫。NI Developer ZoneにはLabVIEW 5で書かれたコードが結構あるんだよね。

LabVIEW Blog, launch!

はじめまして。
ぼくは電機メーカのエンジニア。専門は材料工学。会社では製品の信頼性向上のための研究開発を担当している。
このダイアリで扱いたいトピックはプログラム言語 "LabVIEW"（らぼびゅー） 。一般にはなじみがないと思うけど、LabVIEWは理工学〜エンジニアリング分野で進化したプログラミング言語。米国のナショナルインスツルメンツという会社から発売されているプロプライエタリ言語ですでに20年以上の歴史がある。理工学分野では世界中で使われていて、もちろん日本語版も発売されている。でも、その割にはネット上でLabVIEWの情報は探しにくい。LabVIEW開発環境はおおむね30万円以上するから個人が趣味として使っていることはないだろう。ぼくのように会社で使っているという人が多いはず。でも、ぼくも会社では10年近く使っているけど、サラリーマンのエンジニアが仕事の内容をブログで書いたりしないですからね*1。

でも、この冬状況が一変！オライリーのキャンペーン企画>[http://labview.exblog.jp/12980462/:title]">*2で、ぼくは自宅に自分用のLabVIEW を購入した。自宅に "My LabVIEW" なんて、かっこいいエンジニアだよね。

オライリーさん、本当にありがとう。
ぼく、オライリーの本が大好きなんです。「イノベーションの神話」は今年読んだ本の中で最高の１冊です。役員から新人まで開発に携わるすべての社員に読ませたいぐらいですが、ぼくにその影響力がないのが残念です。


かくして、いちLabVIEWファンとして、仕事と関係なしにブログをはじめてみようかな、ということに。

さて、このブログでやりたいことは 次の３つ。

  1. LabVIEWについての自分の外部記憶。
  2. コードや見解を公開してコメントをもらう（恥ずかしくても、自分の勉強のためだ）。
  3. 微力ながら世の中のLabVIEWユーザに日本語によるガイドをしてみよう。

それでは、Launch! 不定期更新ですけど、よろしく！

*1:Lotus Notesも同じような状況ですね。大企業を中心にワールドワイドで不動の地位にありながら、発売元のIBM以外が発信する情報はとても少ない。ネットばかり見ている人はLotus Notesを過小評価する傾向にありますね

*2:「Make: Japan読者限定キャンペーン」--"新規ユーザ様限定のキャンペーンとさせて頂きます。"との但し書きがやはりここでも微妙な展開を生んだのですけど、結果オーライ！ですよね。 wire_worksさん >>スペクトルカメラプロジェクト開始 : LabVIEW info. Sharing 新館