LabVIEW PythonNodeでMD5SUMを計算
LabVIEWでmd5sum
LabVIEWにもmd5計算用の関数(vi)は用意されていますが、対象はファイルのみです。
できれば文字列から計算できると、便利なんですが対応していません。
(LabVIEW 2020からはmd5sumはdeprecate(非推奨)として関数パレットから削除され、
その代わりにsha checksumが追加されています。また、shasumと同じくLabVIEW2020で追加された
"Byte Array Checksum" 関数でバイト(U8)配列から計算できます。)
Pythonは、hashlibライブラリでmd5やshaをサポートしているので、それをLabVIEWのPythonNodeを
使って呼び出してみます。
MD5チェックサムファイル VI - LabVIEW 2018ヘルプ - National Instruments
15.1. hashlib --- セキュアハッシュおよびメッセージダイジェスト — Python 3.6.13 ドキュメント
準備
Windows用のPython3.6をインストールしてあることを確認します。
Python公式サイトからダウンロードしてください。
また、LabVIEW 2018～2020までのPythonNodeでサポートしているPythonのバージョンは2.7か3.6のみ。
また、LabVIEW 32bit版を使う場合は、Pythonも32bit版をインストールします。
（なお、anacondaでpythonインストールしても、PythonNodeは動きません）
LabVIEW側のダイアグラムとPythonスクリプト
LabVIEW側の処理
LabVIEW側の処理については、以下のVIスニペット画像を参照ください。 同じフォルダにある"Hashlib.py"ファイルに定義している "CalcMd5checksum()"関数を呼び出します。Pythonのバージョンは"3.6"を指定。
Pythonスクリプト
ファイル名: "Hashlib.py"として、VIと同じフォルダに保存します。
ファイル名: "Hashlib.py"
import hashlib
def CalcMd5checksum(str):
return hashlib.md5(str.encode()).hexdigest()
md5の代わりにsha256に変更するだけで、種類を変えることができるはずです。
str.encode()は StringからByteStringに変換するためのもの。
hexdigest()は、16進文字列で結果を出力します。
確認
md5sumコマンドを使って、結果があっているかどうか確認します。
Windowsでもgit for windowsがインストールされていれば、md5sumコマンドが使えます。
$ echo -n "<string>" | md5sum
echo コマンドの "-n"オプションを付けないと改行を付けてからmd5sumに渡すため、LabVIEW>>PythonNode>>hashlib.md5で計算した結果と違ってきます。ご注意ください。
LabVIEW beta プレビューがようやく開始
例年なら、NI-Week開催の半年前あたりからbeta 版プレビュー開始されていたが、
今年は年が明けても音沙汰なし。もう今年はないのかな、と思っていたら、
いつものベータ版登録のページではなく、突然、NIのユーザ向け掲示板にひっそりと
アナウンスされていた。
(そういえば、NXGの開発が2022年で終了、というアナウンスもひっそりとあげられていたような)
今年は、特にベータ版のユーザ登録は不要で、掲示板に掲載されているURLからベータ版から
すぐにがダウンロードできる。
（英語でのユーザ登録やベータ版利用目的の説明を記入して申請、もし不明な点があると、
英語で不明点があって登録できない旨のメールがくることもあり、そこから、さらに登録される
までに数日かかった。)
Runtimeエンジンやドライバのインストーラのダウンロードと同じ形式でのダウンロード。
いつものようにWindows版、Linux版(x86 64bitのみ)、MacOS版が用意されている。いずれも英語版。
暇とPCをなんとか探して試してみたいとは思う。
この調子だと、用意できた頃にはリリースされてそうな気がする。
流行りのNoCode/LowCodeにのせられてみた
はじめに
Google Glide, Microsoft PowerApps, 最近(2020/6)にベータ版が公開
されたばかりのAmazon honeycode、たまたま、この３つを使う機会があった。
まったく深くもない、勘違いしている部分も多々ある勝手な感想。
よく似た３つのサービス、どれを使うか迷う
この３つのサービスにはよく似たところが多い。
特にExcelのような表計算をベースにして、テーブルを指定するだけで、
ほぼ自動的にアプリの雛形を作ってくれるところ。
それぞれのサービスの開発した経緯などの説明を読むと出自や発想となった
考え方に触れられているが、競合するサービスの影響を受けた、という話が
一つも出ない、そういうところまでよく似ている（笑）
GlideとAmazon heneycodeはよく似ている
PowerAppsはNoCodeというより、LowCodeで、プログラミング的な知識も必要、
ただその分高度なアプリが作れるが、まったく知識のない人間には少し敷居が高い。
Microsoftがもともと開発環境を提供していることもあって、それをベースにしている
せいもあるかもしれない。
結局のところ
どれを使うか、というのは、結局、作成したアプリを誰と共有するかによって 変わってくるのかなと勝手に思っている。
Google Glide
不特定多数、もしくは、ユーザ登録無しに利用する、おもにスマフォからの
利用者がほとんどという場合にお薦め。
Glideの良い点は、PWAに対応していることと、無料アカウントでも、アプリの
ログインパスワードをアプリごとに自由に設定できること、これは重要な機能。
パスワードを設定しないで誰でも見られるようにもできる。
（有料アカウントにすれば、さらにメールアドレスによる登録も利用できる。）
URLの先頭部分を、すでに使われている,ものでなければ、任意のものを指定できること、
さらにそのURLをQRコードで表示してくれるなど、かゆいところに手が届く、
便利なツールになっている。
利用にはGoogleアカウントがあればよく、あとは、Google spreadsheetで
元になるデータを作成しておいて、Glideからそれを読むだけでほぼ自動的に作成できる。
アプリの見た目やPWAとして登録した時に表示されるアイコンも、それなりに用意
されているので、アプリを作るのが楽しくなる。
他にもGoogleドライブに保存された画像ファイルをデータ項目の一つとして、
表示させることができる点も、スマフォで使うアプリとしては、画像のあるなしで、
使い勝手や見栄えが雲泥の差になる。これもGlideの大きな利点、特徴の一つ。
展示会などの催しの際に会場マップなどを配信するためのアプリを作るのもよい。
個人的には、グループ間での簡単なパスワード共有や、体温ログなどに使っているが
作成が簡単で実用性の高いアプリを開発できるのがよい。
無料アカウントの制限としては、一つのアプリで利用できるデータ数＝行数が
500行に制限されていること。
ちょっと大きなデータを扱いたいと思った場合は、有料アカウントへの
アップグレードが必要。
Amazon honeycode
2020/6/24公開のできたてほやほやのベータ版、そのための制限、
の可能性もあるので注意。
honeycodeにユーザ登録して、アプリが開発できるようになるが、
開発したアプリを使用できるユーザは、チームに登録した20名まで、
チームに登録するには、honeycodeにアカウントを作成する必要がある。
いまのところ、利用はかなり限定的。
スマフォから利用する場合には、専用アプリが必要。
ソースとして、専用のSpreadSheetデータを作成して、そこから、アプリを
自動的に生成できる。ベータ版なので、現在は、Glideに比べると、かなり、
シンプルなものになっているが、基本的な作り方はGlideとよく似ている。
今後のアップグレードに期待。
Webブラウザ版とスマフォ版の両方のフォームを作成できる。
現在、アプリは英語版しかなく、日本語に設定されているスマフォへの
インストールができない。このため、スマフォ版の画面は私もまだ見たことがない。
追記
リリースされてから1年近く経過するが、いまだにamazon fireアプリ版はない
自社のサービス用なんだから、それぐらいサポートしてくれよ
PowerApps
Microsoft365(旧Office365)を契約しているなら、無料で使える。
利用者は結局、Microsoft365を契約している企業単位になる。
となると、日本では、セキュリティ上の問題から、個人のスマフォ等を
使って、業務用のデータファイルにアクセスを禁止している企業がほとんどだと思う。
そのため、あくまでも社内LANに接続されたPCや、社内LANで使う前提で
登録されたスマフォやタブレットからしか利用できない、ということになる。
個人アカウント
PowerAppsの場合、個人アカウントというのも登録できるが、作成したアプリを 公開することができない、データソースも最初はOneDriveに保存されたExcelファイル になるだろうし、個人アカウントといっても、社内利用目的のアプリの開発のための 学習用であったり、プロトタイプ作成程度にしか利用できないのかなと思う。
最初に使う時の注意
PowerAppsでソースをExcelにする場合、Excelで対象となる範囲をテーブルに
指定する必要がある。
また、Excelソースからフォームを自動作成した場合に、なぜか逆順、列の最後の
方から取り込まれてしまうので、これを毎度並べ替えるのが面倒だ。
しかもそのやり方が、わかりづらく、理解できるまでに、かなり時間がかかってしまった。
さらにアプリの画面のレイアウトは、スマフォ用の縦長か横長しか選択できない。
はじめは、この設定がどこにあるのかも探し回った。Glideに比べると、いろいろな
点で、わかりづらい。
さきに述べたように、日本企業での利用となると、利用者は社内LANに接続
されたPCとなるのに、画面レイアウトにスマフォかタブレットしか想定されて
ないところが、ちょっともったいない。
Excelをデータソースにした場合、最大2000行という制限がある。
データソースをSharePointにすると、その制限は回避できるらしい。
ExcelからSharePolintへの移行も可能らしいが、調査中。
業務用の本格的なアプリにするは、SharePolintやDatabaseなどの利用が必須となり、
それなりのスキルのある人間がアプリを開発することを想定しているものと思う。
余談
一つ、困った点、Excelでテーブルを指定したファイルをOneDrive for Businessに
保存して、開き直すと、なぜか「編集できません」のメッセージが表示される。
実際には編集も保存もできるのだが、最初はこれでかなりとまどった。
番外編
QRコード作成サービス、本家のデンソーウェーブが作るとこうなる、便利なのに無料、
かつ、商用利用もOK！という太っ腹すぎなサービス。
作成したWiFi 接続QRコードを専用アプリで読み取ると、QRコード作成時に登録した
SSIDとPasswordでWiFi接続できてしまう。SSIDとPasswordは利用者に知られずにすむ。
時間制限もできる。専用アプリで読み取るところがポイント！
ただのQRコード読み取りアプリで読み取っても、GooglePlayのアプリのダウンロードの
ページにとばされてしまうだけ。間に専用アプリを挟むことで、そのアプリから、
実際にWiFi接続するまでの間に１クッションおけるので、そこにQRコードと一緒に
作成したウェルカムページを表示させることもできる。考えたなー。
（クルクルマネージャ、なんか、書くと、字面がなんとも。。。。）
QRQR マネージャ https://m.qrqrq.com/
勝手な感想
はたして定着するのはどれか、そもそもNoCode/LowCodeは定着するのか想像もつきません。
個人レベルで作成したクラウドサービスとスマフォとを連携させるのがとても簡単で、便利になったと思います。
以上、勝手な感想でした。
webview+golangでGUIアプリ開発、断念
あえて掲載する内容ではないですが、しばらく時間がたつと忘れてまた同じことを繰り返しそうなので、戒めのために記録しておく。
go get webview であえなく断念
webview使うとgolangでもGUIアプリが作成できそう、ということで試してみた、試してみようと思った。
go get でモジュール追加すればすぐにもできそうな感じだったが、webviewにはgtk3などが必要らしく、apt-getでインストールしようとして関連パッケージを山ほどインストールされそうになってやめた。
ビルドできる頃には目的を忘れていそうな気がしたので、ひとまず断念。
Dockerでgolangのイメージを使えば環境を汚さずにできそうな気がするので、また暇があれば試してみたい。
Windows C/C++
Winodws用にC++でもGUIアプリが作れそうだが、こちらもTDM-GCCというC++コンパイラのインストールから必要になりそう、ということで、こちらも暇があれば試してみたい。
しかし、冷静になって考えれば、GUIアプリを作るならQt(C++)の方が開発環境の構築も楽だと思う。
参考
LabVIEW Linuxで作成した共有ライブラリ(.so)を Go言語で呼び出しdocker+centos+LvRuntimeで動かす
概要
以前の記事、
LabVIEWで作った .so(shared library)を Goから呼び出す
の続き、というか、番外編。
続きといいつつ、LabVIEW 2019にアップグレードしてたりしますが、そこははしょります。
LabVIEWで作成した.soとそれを呼び出す実行ファイルを、Dockerでcentos+labview runtimeコンテナを作って、その上で動かす、という実験をやってみました。
なんの役に立つのかというと、例えば、LabVIEWで何かのデータ解析するすんごいライブラリを作ったとして、Dockerコンテナーで動くようにしておけば、それをAWSとかGoogleCloudPlatform等のクラウドで動かせるようになるかもしれない。
結果
結果としては、動きました。
手順
1. LabVIEW Runtime入りのOSイメージを作成
centosへのLabVIEW Runtimeのインストール、この状態でイメージを作成しておく。
ベースはcentos にした理由は、LabVIEWが正式サポートしているのがRedhad/Centosで、
Runtimeのインストーラもrpm形式となっているため。
Ubuntuにインストールするよりトラブルが少ないはず、と予想。
実際、INSTALLスクリプトを実行するだけで、すんなりインストールできた。
LabVIEW Runtime downloadのページからLabVIEW Runtime installerをダウンロードしておく。
(Installerのダウンロードも wget などで自動ダウンロードできればよいが、URL指定ではダウンロードできなかった。)
dockerfile を作成して、centosをベースにして、ADDコマンドで、/tmpにRuntime installerをtgzのままコピーさせる。
ADDコマンドだと、tgzファイルを指定しても、コンテナ側にコピーする際に展開してくれる。これも便利。
RUN コマンドで、Runtime installer に含まれる INSTALL(bashスクリプト)を実行させるようにする。
/tmpに解凍したときのファイルの状態をls コマンドで確認して、正しいパスに移動してから実行させる。
(docker run /bin/bashでは、rootユーザで実行するので、sudo を使わなくても実行可能。)
ポイント
いきなりdocker buildしても一度にはうまくいかない。
docker run -i -t /bin/bash を使って、手動でコピーしたり、lsでファイルの状態を確認しながら何度か繰り返す。
/bin/bashで動かしているときは、exitでbashを抜けるとコンテナも終了する。
--rm を使うと、コンテナ実行終了時にコンテナも削除されるので、余計なコンテナが残らないので、
心おきなく何度も試すことができる。
example Dockerfile
From centos RUN cd /tmp; mkdir lvrtinstall; ADD LabVIEW2019SP1f1RTE_Linux.tgz /tmp/lvrtinstall/ RUN cd /tmp/lvrtinstall; ./INSTALL; cd ..; rm -rf lvrtinstall;
2. 1で作成したOSイメージを元にコンテナ実行、その中で実行ファイルを動かす
上記で作成したイメージを元にコンテナを実行して、.soと実行ファイルを動かす。
開始時に、Open X-Window で停止してしまうというトラブルがあった。
UIでひっかかっていそうなので、ビルド設定でフロントパネルを削除すればいいのかと思ったが、そういう設定はできなかった。
じっくり設定を調べて見ると、ビルド設定の Advanced に、"Use embedded version of run-time engine" という項目があったので、これをチェックしてビルドすると実行できるようになった。
ビルド設定 >> Advanced 画面
日本語ヘルプでは、
組み込まれたバージョンのRun-Timeエンジンを使用—（Linux）
組み込まれたバージョンのランタイムエンジンを使用して、共有ライブラリを作成します。
フロントパネルまたはユーザインタフェースを必要としない環境に共有ライブラリをデプロイする場合、このオプションを選択します。
Dockerの環境に限らず、サーバ用途でGUI(X-Window)無しでセットアップされた環境で LabVIEWで作成した.soを利用したい場合にも使えそう。
なお、このオプションは、Linux版にしかない。
Windows版DLLは、このオプション無しでも、サービスから呼び出すことができる? かどうかは今度機会があれば試しみたい。
参考
Ubuntu 18とLabVIEW 2019でPythonNode
Ubuntu 18とLabVIEW 2019でPythonNodeが動くようにする
デフォルトの状態では動かない
Ubuntu18でデフォルトインストールされていたのは、python 2.7(64bit)
LabVIEW 2019のPythonNodeで、OpenPythonSessionでエラーになる
原因
LabVIEW OpenPythonSessionでは、pythonの実行ファイルではなく、
libpython2.7.soというライブラリファイルでPythonの機能を呼び出しており、
このファイルが、/usr/lib/x86_64-linux-gnu/に存在することを期待している、らしい。
しかし、Ubuntu18では、そのフォルダには、libpython2.7.so.1、libpython2.7.so.1.0 は
あるが、肝心のlibpython2.7.soがない。
ちなみに、libpython2.7.so.1は、libpython2.7.so.1.0のシンボリックリンク。
対策
対策としては、
以下のように libython2.7.soというシンボリックファイルを作ることで解決できた。
$ cd /usr/lib/x86_64-linux-gnu/ $ sudo ln -s libpython2.7.so.1 libpython2.7.so
libpython2.7.soファイルが作られる。
ちなみに、libpython2.7.so.1の実体は、libpython2.7.so.1.0のシンボリックリンクなので、
最終的に、libpython2.7.soの実体は、libpython2.7.so.1.0ということになります。
libpython2.7.so -> libpython2.7.so.1 -> libpython2.7.so.1.0 (実体)
これで、LabVIEW のPythonサンプルを実行すると正常に実行できるようになります。
(サンプルVIの実行時にPythonのバージョンは2.7を選択する)
LabVIEW Linuxが正式にサポートしているRHEL7/8等でも同じような問題が
発生する可能性があるので、その場合はlibpythonのバージョンを確認してみてください。
余談
なお、
LabVIEW 2019のPythonNodeでは、numpyの配列をサポートしました。
(LabVIEW 2018のPythonNodeではサポートしてなかった!)
最近のPythonのサンプルでは、ほぼnumpyが使われれいるので、ようやくまともに
PythonNodeが使えるようになったのではないかと思います。
ただ、サポートしているPythonのバージョンが2.7と3.6だけなので、せめて3.7には
対応してもらいたいところです。
後日談
Ubuntu20にアップグレードしたら、libpython2.7.soシンボリックリンクファイルが消されてしまったらしく、
実行できなくなっていた。自分で書いたメモを見ながら、再度リンクし直すと、PythonNodeも復活した。
Python3.8がインストールされていたが、PythonNodeがサポートしているのは、3.6。
でもシンボリックリンクを貼り直せば、そこそこ動くのではないかと考えて以下のように強引に3.6.soとしてリンクする。
$ cd /usr/lib/x86_64-linux-gnu/ $ sudo ln -s libpython3.8.so.1 libpython3.6.so
LabVIEWのサンプルで、Pythonのバージョンを3.6を指定すると一応、エラーなく動作はする。
Linuxならではの強引な方法だが、もちろん、サポート対象外なので、いろいろと不都合があるかもしれないので、
利用にあたっては自己責任で。
LabVIEW for Linux 2019 日本語表示
長いこと、期待を裏切られてきたため、今回(2019)もまったく期待してなかったが、 日本語が表示できるようになっている。 しかも、ぎざぎざなビットマップフォントではなく、きれいなアウトラインフォント。 サイズも一応指定できる。 日本語入力もインラインではないものの、テキストラベルや文字列制御器に日本語を入力できる。
UTF8で保存した日本語のテキストファイルを読み込んで文字列表示器に表示することもできた。
LabVIEW Linuxの２大だめな点、日本語表示できない、と、NIデバイスドライバがまともに使えない、 そのうちの一つ、日本語表示がようやく解決された。
制御器表示は相変わらず、縁取りがギザギザでプアーな感じだが、フォントがきれいになった だけでずいぶんと印象が変わる。
Windowsで作成したVIを表示させてみると、フォントサイズの違いで、多少、ずれたり、 はみでたりはしているものの、調整すればなんとか見られるようになりそう。
