LabVIEW における VI の実行状態

LabVIEW でプログラムを作っている仮定で、VI の実行状態に関して困ったり調べたりしたのでメモしておく。

VI というのは、大雑把に言うとユーザー定義の関数である。名前空間的なものを含めて、すべての VI は必ずユニークな名前がある。 GetVoltage.vi とか。

で、プログラム実行中に、VI名を指定して、そのVIの実行状態を知ることができる。状態は、4つで、 「Bad」「Idle」「Run on Top Level」「Running」だ。

Bad は、実行できない状態である。通常、開発システムで編集なので、メモリ上に載っているけれど、コンパイルが通らない状態だ。

Idle は、コンパイルが通るが、実行されていない。

開発ツールのVIウィンドウの実行ボタンをクリックして実行したり、実行形式にビルドしてあって最初に実行されるVIである場合、Run on Top Level という状態になる。main() 関数が最初に動いているみたいな状態だ。

で、Running という名前が直感に反する。VI は、任意の VI の中に配置すると、サブルーチン呼び出してきに呼び出せる。ユーザー定義の関数だから、当然、そういう使い方をする。仮に、Main.vi の中に、Sub.vi を配置しているとしよう。

Main.vi を実行すると、Main.viは「Run on Top Level」状態になる。このとき、Sub.vi の処理自体が実行されている状態でなくても「Running」になる。Main.vi によってメモリ上にロードされて、Main.vi から実行依頼（正確には、メッセージがパス）されているのを待っているときでも、Running になる。

だが罠がある。

デフォルトでは VI は再入可能ではない。Main.vi が Sub.vi を呼び出している間は、他のところから Sub.vi を呼び出せない。実行中の処理が終了するまで、メッセージを渡すのを待つ。

けれど、オプションで再入可能にできる。そしてこの場合は、呼び出しごとにメモリ領域が確保され、「Sub.vi:1」「Sub:vi:2」という風にVI名が識別される。ところが、メモリー上に Sub.vi:1 とかのリストを取得する手段がない。どういうことだよ。なので動いてたら殺すみたいなのをするのに、やたら苦労する。

久しぶりに LabVIEW で並行処理コードをかく

久しぶりに LabVIEW を使って、コードを書いている。UIフレームワーク＋信号処理ライブラリ＋ビジュアルプログラミング言語のIDE というところでしょうか。

National Instruments 製のハードウェア（電圧入力とか、CAN入出力とか、カメラによる画像入出力とかのデバイス）を使うなら、ドライバーとUIで全力で手抜きできる。Init、Start、Read、Stop するためのアイコンを置いて、Read の戻り値をUIコンポーネントに接続するだけでいい。

あと、実行単位が静的に決まっているときの並行処理コードも楽ちんである。

基本的に、左のほうのアイコンから、右のほうのアイコンに、データが伝搬されていく。四角く囲んであるのは、Whileループで、条件が成立するまで繰り返し実行される。

で、上と下の While ループどうしは依存関係がないので、なんとなく並行処理するようになる。両方のループが完了すると、右のほうにワイヤーが集約されたところで join されてめでたく終了する。便利だ。

便利なんだけど、あまりに久しぶりなので、細かいことを忘れていたり、他のプログラミング言語でできたことをうまくLabVIEWの考え方にマッピングできなくて、時間がかかっている。知り合いのトイプー使いが「プログラミングはスポーツみたいなもんで、すっと体が動くようになるといいね」みたいなことを言っていて、まさにそのとおりだと感じている。

Garmin ConnectIQ ウィジェットを作った雑感

Garmin の ConnectIQ 対応 GPS ウォッチのウィジェットを作った。 リオの時刻が分かるという単純なもの。

２つのタイムゾーンで時刻表示するだけなら、そういうウィジェットがあるんだけれど、これは、「リオの時刻を指定して、現在地の時刻を表示」ができる。国際映像とかを見ていて、リオの◯日◯時に次の試合がある、とか言われたときに、こっちでいつのなのかを知りたいであろう。

逆に「現在地の時刻を指定して、リオの時刻を表示」ができる。これは、土曜の午後7時にスポーツバーで集合することになったはいいが、その時間に競技やってんのか？ リオでは何時だっけ？というのを知るときに使う。ちなみに日本で午後7時は、リオの午前7 時なので、試合のライブはないであろう。マラソンでさえ、9時半スタートである。

Connect IQ のウィジェットというのは、時刻表示モードのときに、ワンアクションで簡易的に表示/操作ができるアプリだ。たとえば天気だとか、スマホの通知とか、カレンダーとか、そういうのを見るのに使う。複数タイムゾーン時計のウィジェットも存在する。

今回作った、RIO Clock は「現在地/リオの時刻を指定する」という操作がある。で、このUIにちょっとだけ苦労した。

まず技術的には、picker クラスを継承することで、時刻を選択できる感じがあったのだけれど、挫折した。かなりプリミティブに描画を実装する必要があった。何がだるいかというと、機種ごとに画面サイズがばらばらなのだ。動的に計算できるんだけど、時刻を選択するだけなのに、やりすぎだろうと。

そんなわけで単純に、1時間単位で、次/前を操作していくことにした。したんだけど、もういっこやっかいなのが、操作イベントのとりかた。

何かを選択するときに、up/down ボタンを使う系の機種と、タッチパネルをスワイプする系の機種がある。物理的なイベントを検出してコールバックする InputDelegate というクラスがあって、これを使うと onUpButton とかを検出できる。けど全機種とかだるい。

BehaviorDelegate というクラスがあって、こっちはもっと抽象化されている。たとえば何かを選択するときには、up/down をしたときであれ、スワイプした時であれ onNextPage が呼び出される。onNextPage とかが標準的なUIに対応しているのであろう、と信じて、これを使うことにした。

ただ、上下で選択なのか、左右で選択なのかは、機種ごとに違うので表示がことなる。まあしょうがない。画面サイズも違うので、機種ごとに表示位置を定義するXMLを書いた。

それって、いくつあるんですか？

クリエイティブ案件のシステム開発（広告・プロモーション的なウェブサイト/ウェブアプリのサーバーサイドの開発および運用の意味）を請け負うとき、最初にオリエン（オリエンテーションの略と見せかけて、発展途上な思いつきを聞く会）に参加する。

いろいろと細かいことや、突飛なこと、素敵な意見が出てくる。おお、まじか、そんなのいくらかかるんだ、とか最初は思っていた。けれど、この時点で明確なドキュメントになっていないのであれば、ソフトウェア開発の文脈においては、基本的にwishlistの作成中だと思ってよい。

ただ wishlist のままでは開発はできないし、だいたい見積さえできない。要件を曖昧にすることはできても、曖昧なプログラムを作ることはできないからだ。

どうせいろいろと変わってくるんだけれど、自分にとっての要点の整理と、気にしている事項を伝えることを目的に、早い段階でいくつか聞くことがある。

そのひとつが「それって、いくつあるんですか？」だ。

たとえば、ロレアルのMakeup Genius というアプリを考えてみよう。今年、広告賞をとったやつを適当にググっただけであって、私は一切関わっていない。

カメラに自分の顔を撮った状態で、ロレアルの口紅を選んだら、その口紅を使ったメイクが画像に反映される。ロレアルの製品をリストから選ぶこともできるし、バーコードでスキャンもできる。シェアしたり、いいねしたりもできる。プロダクトが気に入ったら、購入ボタンで販売店（ドラッグストアとか）の購入ページに遷移する。

• 製品カテゴリーっていくつ？
• チークって何色あるんですか？ 組み合わせとかもあるんですか？
• いいねできる製品の数は？
• ひとつの製品に、何度もいいねするんですか？ それとも一回だけ？
• 国や地域を設定できますが、これはいくつ選べるんですか？
• Facebook にログインしますけど、友達とか取得します？

基本的に知りたいことは、必ず1個、0または1個、0以上の、どのカテゴリに属するのかだ。

必ず1個なら、テーブルのカラムに入れることができそうだなぁ、などと考える。ユニークなの値（Facebook のアカウントとか）ならキーにできるし、重複を許さない機構がいることになる。

0または1個の場合（メールアドレスとか）、0以上の場合（いいねとか）とでは、当然データの持ち方が変わってくる。

wishlist の段階では明確に決まっていないであろう。どのくらい決まっていないのかを確認できればよい。

「何度もいいね」とか意味が分からないであろう。けど、これは重要である。Facebook の投稿本体には、ひとつしかいいねできないんだから、1つだと思うだろう。

けれど、コメントにもいいねができる。だから、他人がいいねした内容に、自分ものっかっていいねする機能もあって当然だよね、と思う人が世の中には存在する。

スマホのFacebook メッセンジャーでは、いいねアイコンを長押しすると、アイコンがでかくなる。あれも含めてFacebookのいいねだ、と考えると、「Facebook みたいにいいねするだけ」の奥深さに驚愕する。

このとき、なんとなくクラス図や、ER図に近いものを描いていく。可能なら見せる。「いや、そんな複雑な話じゃなくってさ、いいねするだけなんだよ」と言われるかも知れない。それでもいい。作りたいモノの本質的な複雑さを分からずに発注しようとしている、ということが明らかになるのは重要だ。