2017/02/18

可変長レコードに苦しむ

VBと固定長データ
Slip21 のデータファイルは固定長で保存している。というのは以前,可変長をトライしてみたのだが上手くいかなかった。今回 TWE を取り扱うに際し,とりあえず1個のモジュールだとこれまでの最大3個のモジュールを想定していた固定長だと余りにも空白部が大きくなる。

2日ほどトライして,VBFixedArray の修飾子を取り外したら可変長にはなるようだ。しかし,可変長サイズがきちんと計算されないのか,レコード数と合致しない。この種のプログラミングを数年前に眠っていた VB3 を引っ張り出して始めたのでそれは古いコードが元になっている。VB.NET 以降から初めていたら,ArrayList で設計しただろうと思う。

何せ,35年前の FORTRAN の経験が私のプログラミングスキルの元になっているので配列を切るのは,ごく当然だった。当時は配列を固定長でプログラミングした。固定レコード長の計算に使用する関数 Len は,信じられないけど動的配列ではうまく動作しないだろうか。ArrayList を使用すると,計算式を作成しなければならないからあり得るか。

FORTRANの思い出
当時の情報系の研究室なら,Cでプログラミンしただろう。取り扱う対象が機械系のシミュレーションである有限要素法だったから FORTRAN だったのだろうか。しかし,当時フランス人が執筆した有限要素法の数千円の古書が,1万円近くで売れた。実際にこの種のプログラミングしようとすると,日本の類書は最初と終わりの記述はあるが,途中とか技法がとんでいるのが多い。それは著者が実際に,理論を考え実務をせずに執筆するからだろう。日本学者による半導体,応物のテキストは 300円 でも売れない。この価格以下だと手数料を考えたら赤字になる。

汎用の有限要素シミューレションプログラムなら市販されているので,特殊な用途のプログラミングに購入したのだろうか。粘弾性とか異方性材料なら自分で剛性方程式を求めシミュレーションしなければならない。昔はメッシュ切りが大変だったけど,今では汎用プログラムが良くなった。

迫撃砲の価値
タングステン弾芯が装甲に激突して,高温ジェットになるシミュレーション映像があった。イラク戦争とか2次大戦で破壊された戦車砲塔に貫通した穴の写真をみるとそうかなと思う。現代の陸自は1週間分の弾薬はあるといっているが,戦闘地域に輸送する「手」がない。例えば,韓国軍が対馬に上陸しても誰が物資を運ぶのだろうか。対馬上空は韓国空軍の制空権範囲だろう。避難計画を立案しても避難バスを運転できる県の役人がいないのと同じだろう。満州と朝鮮から脱出する軍人役人家族専用列車は仕立てられた。対馬は県として沖縄同様に独立した方がいいだろうと思う。長崎県の役人が立てた計画など役に立たないかもしれない。

本土決戦に備えて,書類上は大砲弾は10%の定数があったとされるが,天皇の特使が視察したら九十九里浜とか四国の急増師団の充足数はゼロだった。輸送する弾もないせいか,軍馬もなかったそうだ。対戦車砲と迫撃砲は米軍相手に必須兵器なのに三桁の師団番号には全く配備されていなかった。銃砲は実包で訓練しないと使い物にならない。沖縄戦とかフィリッピン戦では満州に配備されていた師団が振り向けられ,それなりに迫撃砲を取り扱えた。迫撃砲は直射せず大きな放物線を描いて着弾するから訓練は必須だった。遮蔽物に隠ぺいした敵兵を追い出すのに今も昔も有効だ。日本陸軍の小口径迫撃砲に苦しんだ米海兵は今でも訓練して使用している。動画をみると習熟しないと使い物にならないとわかる。硫黄島と沖縄でちっぽけな迫撃砲で日本陸軍が善戦したため,降伏が遅れ原爆も投下されてしまった。喧嘩にしろ止め方を考えて,戦わなけばならない。負け方を知らなかったか,それとも単に無責任だった日本の指導者だった。その点,イタリア指導部はスマートだった。

ドイツ連邦陸軍はほとんど迫撃砲を配備していない。ドイツの仮想敵であるロシア陸軍は機械化されていて価値がないのだろうか。それとも,ドイツ軍といえども訓練して技量の維持に困難なのだろう。さらに高等なスキルを要する機甲兵の維持だけでも目一杯か。オランダ陸軍は金食い虫の戦車をトルコに売却した。それにしても米海兵は不思議な軍だ。ゲリラ掃討戦を戦い,機甲戦もする。究極の諸科統合部隊か。日本の空自と陸自では無線方式が異なり,通信もままならない部隊がある。どこの陸軍でも空軍機の統制指揮官が指揮車に乗車して爆撃(砲撃代替)を実施する。米海兵だと,海上の指揮艦から海兵隊および海軍機を統制した。日本の自衛隊の3軍はいつ統合されるのだろうか。身近なところをどう守るかを考えず,何となく軍事力を整備してきたのだろうか。典型的な官兵でしょうか。

データベースエンジン検討
数日間,レコード長を二分してトライしたが,やはり Len を用いたファイルの書き込み自体がうまくいかない。フリーのデータベース MySQL は Windows XP で動作するようだ。しかし, Windows 10 だと対応のバージョンが異なる。異なるバージョンのエンジンを常用PCとサーバに別にインストールしたくはないが,仕方がない。

MySQL Connectors に "MySQL provides standards-based drivers for JDBC, ODBC, and .Net enabling developers to build database applications in their language of choice" とある。VB2010 Express は Microsoft 固有の ADO.NET を取り扱えないので没。MySQL は JDBC ドライバが用意されているので LibreOffice BASE とか Calc に取り込めるだろう。言語が選べるといっても,インストールすらしていない言語ばかりだ。

データベースに接続するアプリの言語は PHP かCになりそうだ。既に Eclipse をインストールしているし,AVR Studio も Eclipse ベースなので Microsoft Visual Studio を使う事もないか。しかし,PHP が使えるそうだ。VB による私のコードはまだ続きそうなのでシームレスに他言語に移行できる Visual Studio にも魅力を感じる。迷うな。マイコンから Html までは Eclipse,データベースは PHP ではなくCが無難か。

ODBC ドライバを用いれば,MySQL も使わずに済むかな。FC2 の場合だと,データベースは月額 300 円かかるのに容量 100MB しかなく,長期計測用には不向きだ。ODBC データベースにしておけば,MySQL は使えないけど Windows からアクセスできるそうだ。データベースエンジンの可視化には LibreOffice の Base を使うつもりだ。

実際に LibreOffice を開いて Base 対応データベース一覧をみると,日本語 LibreOffice の説明と異なり ODBC の他にJDBC, Oracle JDBC, MySQL がリストアップされている。これもまた迷うな。やはり,Java が王道か。そう言えば楽天の三木谷氏が Java プログラミングをやりたい(習得の意?)と言っていたのを思い出した。日本では人材が集まらないのでシリコンバレーに本社機能を一部移転するそうだ。タケダ薬品,本田技研,そしてあの東芝ですら15年程前に研究拠点をイングランドと合衆国に設置した。頭脳争奪戦が厳しくて,どうにもならないのか。

初代 PS の心臓部開発は東芝と IBM が担った。10数年前の当時からPSの GPU は 128bit であった。スキルのある欧州の計算機学者達はスパコン代わりに使ったそうだ。思いもよらない発想が日本人には不向きのようだ。その開発を担った社員とワークステーションを東芝は全社から湘南にかき集めたそうだ。逆にそれだけのデジタル技術者がソニーにはいなかった事を意味している。これほどまでにデジタル技術に日本が後れをとるとはどう考えたらいいのだろうか。米英と台湾韓国中国がつき進めるのはなぜか。通信技術の大手ノキア,エリクソンの欧州勢はデジタル技術革新の波に乗れず撤退した。デジタル技術に弱い日本がデジタル通信機器を商品化するのは無理があったか。そういう私もデジタルなら簡単になるのについアナログへと傾斜しがちだ。それでもヤマハなどはシンセサイザーに乗り出した時,社長は開発費が資本金と同額と聞いても投資した。ヤマハのモデム用チップもあったけど,いつの間にか消えた。今では信じられないが日立は CODEC を製造販売していた。旧い欧州と日本に何かしらの共通性はあるのだろうか。欧州と日本のハイブリッド技術者はその後,どうなったのだろうか。それでも欧州はEUの障壁がある。ドイツ民族悲願のラインの守りはEUに結実した。TPP はトランプのちゃぶ台返しで頓挫した。戦前のような日本の迷走が始まるのだろうか。

東芝は医用デジタル画像部隊をキャノンに売った。古色蒼然とした原子力が残るのか。ビルゲイツが投資している東芝の新原子炉はどうなるのだろう。明治の元勲は富国強兵策をとり,殖産興業と朝鮮進出を計画した。今思えば,この政策がよくなかった。経産省による国家主導の経済政策が新産業の芽をつんだきらいがある。国内の半導体メーカは大手ばかりで,台湾中国のような斬新なチップメーカが育たなかった。何が明暗を分けたか。ソニーが中国で学生をリクルートしても獲得できないそうだ。潮目が変わったのはハイビジョンテレビだった。日本の HDTV の H はハイブリッドだった。デジタルはアナログ技術の補完だった。集積度があがらず複雑なチップになってしまう規格が世界主流になると考えた NHK 経産省メーカがおかしかったのだろう。どうして日本人は簡単な事を複雑にするのか。江戸時代に田んぼの馬耕を人力耕起に転換した発想とどこかでつながっているような気がする。道具を発明したり改良するのが苦手だ。流民が大発生しても中国は人力耕起に回帰する事はなかった。殷代の王は戦車に乗っていた。中国の人力耕起は太古の河姆渡遺跡とか殷代の奴隷くらいだろう。春秋戦国期は戦車と弩(ボウガン)が兵器の主流だった。平和な日本では籠城戦もなかった。中国の城とは都市の城壁を意味していた。日本のシロと中国の城は異なる。それと日本には中国のような都市国家が形成されなかったのも大きいと思う。ソニー本社は品川村にあると思えば,中国人学生が就職を希望しないのもわからんでもない。中国の農民戸籍を離脱するには留学,合衆国市民権の獲得が手っ取り早い。その合衆国が中国移民を制限し出した。戦前の排日運動と似通っている。トランプは中国人の移民枠を激減させるかもしれない。その中国も若い活力があるのは高齢化のため20年も続かない。もうそろそろ中国マーケットと人材を期待するのはやめたらどうだ。

加齢が進むと,手足の微妙な制御ができなくなる。実際は手足の運動機能が低下しているのではなく脳機能が低下している。最近,老人の交通事故がニュースになる。脳が衰えているのだ。男はタバコ,アルコール,コーヒを嗜むから余計に加速する。トランプはこの種の嗜好品を避けているそうだ。脳のために良い。コーヒの喫飲を止めて何年になるだろうか。それでも,脳機能の低下を常に感じる。

XBee と TWE の併用
可変長レコードを二分する試みは失敗した。最大モジュール数を4に拡大し,XBee の他に TWE を追加する構想の実現は困難になった。それに COM ポートを2個同時に使用するプログラムはそれぞれを時刻に同期させるのも工夫が必要になるし,開発要素が増えてデバッグ時間も倍増するので諦めた。

そして,XBee と TWE を併用するユーザがどれだけいるか。さらに最近のPCなら個別に Slip21 を併用動作させても問題ないだろうと思う。

参考

2016/11/19

Slip21 UAC トラブル

Windows 10 下の Program files(x86) に Slip21 をインストールすると,Meas.txt が書き込めなくなる。
Windows VistaからUAC(ユーザーアカウント制御、User Account Control)が導入されました。このUACが有効になっていると、Windows XPでは正常に機能していたアプリケーションでも問題が発生する場合があります
とあり,スタートメニューから右クリックして,「管理者として実行」してもらう事にした。

最初,Debug 版だと問題がなく Release 版だとトラブった。コードのガベージコレクションが関係しているのかと思い,Close と Dispose についても調べた。Meas.txt のファイル属性を読み込みのみとしていたけれど,その制限を外しました。

参考
2016/10/13

Meas.txt 月初めに先月末日の結果を表示しないバグ改善

Slip21 には過去24時間の測定結果を LAN 内PCに書き込む機能がある。この機能により,Web にも公開している。しかし,毎月の月初めに,前月末日のデータを表示しないバグがあった。

10月1日に実際にこの現象を体験して,自席を離れてサーバまで見に行くのは億劫である。この現象が起きる頻度は 12/365 すなわち確率的には 3.3% に過ぎない。このデバッグをして,元旦と3月1日だけが,大晦日と二月末日の測定結果を表示しないに改めた。その割合は 0.5% に改善されたと思う。というのは,実際のテスト結果は月初めにだけわかるから。

Now.Day だけで現在の日にちがわかることをしった。Slip21 は当初 VB4 で作成され,.NET Framework のリソースを一切,使用していなかった。VB2010 Express は無料だったので使い始めた。構造化プログラミングとかオブジェクト指向と言うらしい。よく理解せずに恩恵にあずかっている。MSDOS の日付時刻コマンドを関数にしただけの BASIC 関数を利用していたら,変数宣言さらに Format 文も必要だった。

極端な話,ドットを用いて記述すると,かなりの事ができるが,どんな物が用意されているのか知らないと宝の持ち腐れになっている。プログラミングは言語の学習と同じで,大脳が青少年の時に習得しないと,高度のプログラミングに慣れるのに不利になる。日本の状況は絶望的だ。何せ,東大受験に漢字の書き取り問題が出るような国だからだ。漢字を習得するために,若い頭脳を浪費している。頭脳を浪費しきった大人がサラリーマンとりわけ官僚だろうか。サラリーマンとか官僚は実務を何も知らなくても出世できる。大手企業の社長がどれだけ実際に,手形を目にした事があるか。官僚がどれだけ,実際に国債を目にしているか。おそらく黒田日銀総裁は手形と国債の現物を取り扱った事がないだろう。不思議な国だ。

全体を見通す指導者を嫌う文化のせいだろう。指導者は棚上げ,神輿状態になる。創業の精神が失われると,「空気」が物事を定めていく。

日本語にはスペースがない。カンマ,スペース,ドット,コロン,セミコロンの違いを欧米の子供は小学校から習得する。漢字教育もいいけど,せめてローマ字,欧文の記述形式を小学校で習得させたらどうか。現場と親の反対で無理だな。受験に何も役に立たないからだ。航空機を操縦した実務のない海軍大佐が空母の艦長になり,指揮をとる。実務をしない空理空論で作戦を立てる。日本に合衆国のマイクロソフト,グーグル,アップル,アマゾン,オラクルのような企業が育たないのは「金」の問題ではない。実務をしない精神からだろう。頭のなかだけの抽象アイデアだと,官主導の日本の第5世代計算機プロジェクトのようになる。国民も官僚に創造性を期待するのもおかしいと思わないのもおかしい。

参考
2016/04/08

Slip21 高精度温度センサ表示

高精度温度センサ HDC1000 の出力を Tera Term に表示できたので,これを Slip21 に取り込む事にした。古いバージョン の Slip21 では MCU H8 を用いた温度測定をしていた。これを再利用すれば簡単だろうと思いトライした。

測定表示はすぐできたが,同時に測定時刻を表示させようとすると上手くいかない。表示できたり,できなかったりする。現象が毎回同じでないデバッグは嫌気がさす。5日間,ダラダラとデバッグしていたら,VBの文字列処理が通信に間に合っていないのではないと思い当たり,改善したら表示できるようになった。

数年前なら,こんなにデバッグに時間を要する事もなかったのだろうと思う。老化というかボケたのかな。
HDC1000MCU.png

H8-Query の M1? を選択して Out ボタンをクリックすると,温度湿度そして改行して測定時刻が表示される。AVR とPC間のシリアル通信は無手順で行っているから,PC側はそれなりに高速処理をしないとバッファがフルになってしまうのだろう。「Stringオブジェクトには、その内容を変更することができないという特徴があります」とあって,何と処理時間は3桁も違う。

参考
文字列処理を高速に行う