年明けから、まさにタイトルのとおり。
とくに今週は。
日曜晩に東京で前泊?月曜は長野、夜に新大阪まで移動。
火曜朝移動で鳥取県をかすめて岡山の奥地へ。水曜まで滞在。
水曜の夜に名古屋までたどり着き、木曜(本日)朝 横浜にて一日打ち合わせ、夜移動し愛知県内の工場へ。 先ほど終わってホテルで執筆中。
金曜(明日)引き続き工場立会いが終わったら、兵庫県へ移動、土曜日に打ち合わせして、ようやく千葉県の自宅に帰る、、予定。
今週はピークだけど、今年に入ってからこれに近い状況。 1?2週間分の荷物を携えてのこの手のどさ周りが3月頭まで続きまする。 そろそろこういう生活はきつい年頃。。 誰か助けて。[E:rightdown]
皆さま、遅ればせながら今年もよろしくお願いします。
(昨年 義祖母の不幸があったので、このご挨拶にて失礼します。)
さて、積層スピーカーの会から始まり、ここ1年、数々のXoopsサイトを立ち上げてきました。 そしてようやく、自分の納得できる 仕事関連の [本気モード] ボランティアサイト
「Motion cafe」 http://www.motioncafe.net
を、稼動まで漕ぎ着けることができました! (←のリンク集にも追加)
...最近、プロジェクト物の機械担当としての仕事を手がけているため、平日はプロジェクトメンバーの揃う事務所への出張がほとんどです。
その場その場の水の流れに逆らわずに泳ぎきることで先に繋がる、とはいうものの、やはりプロジェクト物は私には合わないと感じます。
A:プロジェクト物のメリット
1、設計?立ち上げまでの日当単価で会社は売り上げが立つので、損益的には有利。
2、片道3時間かかり、現実的に毎日日帰りで通うのは無理。 宿泊出張として請求できるので、個人的な日当に余裕ができるので、毎日のお小遣いが入ってくる。
3、営業活動をしなくても、色々な話が耳に入ってくる。
B:プロジェクト物のデメリット
1、以前の設備図面を見ながらの作業となり、基本的に出張が主体となる。
2、単身赴任ならば、勤務地近くに自分の部屋が準備され割と自由が効くのだが、ホテル住まいだと同じホテルにずっと泊まれるとは限らず、荷物の持込(保管)も大変。 日常のトレーニング用の靴や衣類なども置いておくにはちょっと。。
3、都会の道を走るのは、やっぱり危険。 食事も外食で偏りがちで、健康維持のために週末に家でトレーニングするしかない。
4、出張中サーバーのメンテができないので、万一ダウンしたらお手上げ。
5、何より本人のモチベージョン維持が難しい。
ということで、自分的にはプロジェクト物よりも開発物、ソフト仕事がやはり向いているなあ、と思う今日この頃。
最近どっと仕事が舞い込んで、(社長としてはありがたいことですが、同一人物の実担当としてはため息ばかり) 首が回らなくなってきました。 電気制御だけでなく、昔取った杵柄でメカの仕事が半分を占めます。 久しぶりに燃えないと。
半分は東京?横浜出張なのですが、6/11?22に北九州が入ってマフ。。 6/17(日)のソフトテニスの試合(大学OB会の杉並大会団体戦)に、往復6万円かけて帰ってくる?!? 見積もりもそれで出してるんだから、甘えちゃうか。 ポケットマネーからは絶対に出す気にならないけど。
そして、スピーカーのコンテストの結果は6/10過ぎに出るでしょうから、万一予選通過しても、本戦に出るまでに何もできない、、去年と同じ状況。 したがって、忙しくてもなんでも、ここ10日間に色々やっておくしかないわけです。 せめて、スピーカー端子くらいはきちんと付けよう。(爆)
二兎を追うもの一兎を得ず、しかし三兎を追えば二兎くらいは得られる可能性あり、、ってのは滅茶苦茶か。(笑)
・・ そんなわけで、明日6/1はミクシの某ナイターテニス練習に、でかけるぞ、ほい!
追記: LAFESTA cafe. ステッカー販売準備も、やんなきゃ?。。
現場には4年ほどぶりになります、 豊田スタジアム。 OPENから5年半経った今でも、日本一、いやおそらく世界一難しい動きをしている開閉屋根だと思います。
今回は、とある名目での開閉屋根運転ソフトの改修案件で現調に行って参りました。 初めにお断りしておきますが不具合修正ではありません、ご安心くださ い。 ソフトの中身も決して難しく作っていませんが、その機能の多さ・奥深さゆえに、今でもソフト変更の際は私まで依頼をいただいてます。 ありがとうご ざいます。
以下、個人的な宣伝の一種と思ってください。
私の今の本業は、汎用ACサーボモーターのコントロールですが、この物件はサーボはありません。 14台のトラス(橋梁)の左右にある台車走行を遠隔でイ ンバーターの速度制御を行い、東京ドームの類のエアーマットとそれを支持するつなぎ梁との速度協調運転で、閉めたり開けたりするものです。 開閉所要時間 は、片道約1時間ほど。 動く物の総重量は、何と2000トン! そんな重量物が屋根上に乗っているんです。
閉め始めはカーテンを広げるように伸びてゆきますが、屋根の開閉動作の最大の見せ場は、最後に待っているつなぎ梁との速度協調運転です。 →は北側の道 路から見上げた写真ですが、これに写るワイヤーを一定速度で引っ張ることで、つなぎ梁自身が持ち上がります。 (正直言ってこの下は歩きたくありません。 何か落ちてきそうな錯覚が襲ってきます・・)
右の写真は、先頭トラスが協調運転中の写真です。 台車の速度は、つなぎ梁で拘束されて変形三角関数で徐々に低下させねばなりません。
この速度変更を2次関数に近似し、近似しきれない部分はインバーターとモーターの「電動機的すべり」によって解消するものです。 これを13回、各々微妙に異なる係数でリアルタイム計算し、屋根が開閉します。
(余談ですが、この制御盤の位置には参ります。 トラスの上を歩いて行って、ハッチからここに梯子で降りるときの恐怖感は相当なものです。)
この台車駆動、基本構想とその他色々な情報をいただいた以降の数値化リモデル・近似式作成・ソフト思想と設計・コーディングまでのほとんどを、提 案?作成まで(もちろん、多くの人との情報交換を経て)行いました。 (「生き物」と言われるエアーマットも煩雑な動作をしており、24時間継続運転する この部分のソフトは当時の同僚が作りました。 )
この手のメカメカしい物体のモーション制御は、私のような機械屋が設計することのメリットは非常に大きく、設計段階から危険予知を行いつつ、現調までに事前シミュレーションで完成度を上げておき、現場改造にもシミュレーターを活用することで安心して立ち上げを行うことができた訳です。
しかしまあ、こんなに手間暇かけて作っても、現調前には「台車がオーバーランして屋根から崩落する夢」を見たりしたものです。 今では笑い話です が、これだけの大物を制御室から遠隔でタッチパネルのスイッチ一つで動かすのは、自動運転以上に神経をすり減らされました。(笑) 当時は「もうやりたく ない」とも思いましたが、今では「またやってみたい」と思うことも(汗)。
一昨日は吹き飛ばされそうな強風と強烈な花粉に悩まされました。この時期は本当に辛い・・ 一方、お昼は(作業着のまま)4階のレストラン「 ヴェルデロッソ」で週代わりランチをいただきました。 メインにビーフシチューか海老の何かか選べましたが、シチューは美味しかったです。 海老は・・
ようやく、仕事用の液晶モニタを購入しました。
これです。→ RDT214S(BK)
(21.3インチ、税送料込で87千円。)
14.1"のThinkPadT42が小さく見えます。
20インチでも良いと思ったのですが、現在使用中のThinkPadT42 (2373-J8J)の液晶が14.1インチ/解像度1024x768ピクセルなので、 これより文字が小さくなると視力低下が加速すると考えて、21.3インチを奮発しました。 (厳密には文字は若干小さくなりますが・・)
サイズ 14.1" 20" 21.3"
解像度 1024x768 1600x1200 1600x1200
画素ピッチ 0.278mm 0.255mm 0.27mm
ノートPCなので、アナログRGB表示ですが、まあ仕方ありません。
デスクトップPCで仕事をしても良いのですが、何かあってもすぐに出張に出れるようにしておくことと、その他多少の事情によります。
これでマルチモニタで、片方にVirtualPCのWin2000の仮想OSで、シリアル通信中も他の仕事がサクサクできます。 (今までは、通信中は通信ソフトの出来が×で何もできなかった) ついでに、「1つのOSに1つしか開けないアプリケーション」を仮想OS上でも開いて参照しながらホストOS側で作成できます。
冒頭の写真では、モニタの方にWin2000を表示しています。 昨日正式に公開されたVirtualPC2007では、マルチモニタ側でも全画面表示ができます。
少し仕事にやる気が出てきました。(笑)
1年に2回くらいしかやらない、PCのプログラムが必要な案件が来ました。
某スタジアムの開閉屋根の走行プログラムの改造。 本体制御はモーション制御なのですが、改造のシミュレーションをパソコン上のシミュレーターを使って行うものでして、そのシミュレーターのプログラムです。
以前は、VB6のタスク2つで、中間をC+の共有メモリで繋いでいました。 これをVisualBasic.netに移行して、ネイティブなマルチスレッドで1本化するものです。
ご存知のとおりVB6->.net 移行の際のネックは色々ありまして、単純にプロジェクトのアップグレードで動く物の方が少ないくらいです。 一番困るのは、「コントロール配列が使えない」ということでして。。
このように、14台ある物体の各ランプを種類毎にまとめたり、数値表示を出したりといった使い方ですから、まず間違いなく コントロール配列を使ったほうが簡単でコードも読みやすいです。
VB6なら、コントロールをコピー?ペーストすると、勝手にコントロール配列にしてくれました。 Label1でしたら、Label1(0)、Label1(1)・・ という具合です。
しかし、.netに変わってからは、Label1をコピーすると、Label1-1、Label1-2・・となってしまいます。 オンラインマニュアルを見ると、
「Visual Basic .NET では、コントロール配列はサポートされません。イベント モデルに加えられた変更により、コントロール配列が不要になりました。Visual Basic 6.0 では、イベントがコントロール配列によって共有されていましたが、Visual Basic .NET では、複数のコントロールからのイベントがイベント ハンドラによって処理されます。このことにより、同じイベントを共有する異なる型のコントロールグループを作成できるようになります。」
とあります。
一般的には、 こちらのサイトにあるような方法が簡単にコントロール配列を作れるでしょう。
ただ、クリックイベントなどの際にどのコントロールが対象なのかを判断する時の処理がわかり辛かったり、同じコントロールの配列群を多数set作る 場合などを考慮し 私の場合はコントロールの配列は 「System.Collections.CollectionBase」 クラスを継承したクラス で 「ControllArray」による方法を使用しています。
これは、予め汎用的なControllArrayクラスを作成しておけば、追加呼び出しなども自由ですし、よりオブジェクト指向の書き方になってきます。
**
まあこの程度のことは、プログラマの方からすれば「何を今更低次元な。」 なんでしょうが。。 これが本業でないプログラマにとっては、結構面倒なわけです。
さて、42setのコントロール配列群をやっと作り終えたので、本体コード移行に着手しなければ・・