00:08
こんにちは、常蔵です。
デザイン・リビューFM第74回目、始めていきましょう。
このデザイン・リビューFMは、世の中の様々なもの、主に工業製品について、私の主観で勝手にデザイン・リビューをしていこうという番組です。
前回、73回目では、産業機械のメカ設計者が考える電線のことというテーマで、メカ設計者が設計を進めていく中で、電線についてどんなことを考えているかというお話をしてみました。
ソフトウェアの重要性
今回は、メカ設計者が設計を進める上で、ソフトウェアについて何を考えて進めているかということを話してみようと思います。
まず、産業機械、その中でも工作機械のソフトウェアがどれだけ重要かについて触れてみようと思います。
今の工作機械は、高精度で複雑な加工を行う必要があります。
その機械の動きを正確に制御する必要があります。
正確に動作させるためのソフトウェアは欠かせません。
ただ、そこら辺の部分は、NCメーカー側の制御を基本的に行っています。
メカ設計者があまり触らない部分です。
それ以外のソフトウェアは、実際に加工をするためのプログラムと言っても、
メインのXY軸や5軸のテーブルなどのメインの軸を動かすための部分と周辺部分、
ATC、工具交換装置、パレットチェンジャー、クーラント関係、工具測定装置、
周辺装置の制御は一段下のレイヤー、裏で動いているようなところではありますが、
そういうソフトウェアの方が絡むことが多いのかなと思っています。
どういうもので制御しているかというと、送り軸関係は、
NCだったり、周辺のところはPLCを使っていたり、NCを使っていたり、
そういうところで軸の動きだったり、スピンドルの制御をリアルタイムで制御している部分とか、
あとはラダーとかを使用してシーケンシャルに動作をさせていく部分とか、そういう部分があります。
また、操作版の画面のユーザーインターフェースの部分だったり、
機械の状態をモニタリングする機能というのもソフトウェアによって実現されています。
私たちメカ設計者というのは、こういうソフトウェアが機械のハードウェアとうまく連携するように、
設計段階から考慮しなければいけないということですね。
メカ設計の構想段階からそういうソフトウェアを意識することは実はあまりなくて、
何か動作する機構を持つユニット、装置を設計するとしましょう。
複雑に見える装置だとしても、まっすぐ動く部分と回転する部分に分けられて、
モーターだったり油圧だったりエアシリンダーの組み合わせだったりします。
だいたいはシーケンシャルな動作になるんですね。
ABCという3つの動作する機構があったとすると、まずAに動けと命令をするとしましょう。
その後にAが命令した動作を完了したかどうかを確認して、
Aの動作が完了したと確認できたら、次にBに動けと命令する。
またBも命令された動作を完了したと確認できれば、次にCに動けと命令する。
という感じにシーケンシャルな動きをさせるというのがほとんどですよね。
それら一つ一つの動作を分解していくと、それらは本当に単純なことをやっていて、
それらの組み合わせでソフトウェア的にそこをできませんと言われることはほぼほぼないと言っていいと思います。
設計段階での協力
メカ設計を進めていく上で、ソフトウェア設計者との関わり方、どう関わっていくかというと、
まずは設計を始めるときですね。
こんな新しい機械を作りますよとか、こんな新しいオプションユニットを作りますよとか、
こんな特殊仕様をやりますよという宣言をするときですね。
そういう宣言をするときに打ち合わせをやったりするんですけれども、
その打ち合わせの場でざっくり装置ユニットの全体像というのを説明して、
新しく作るものの仕様だったりスケジュールですね。
一番大事なのがスケジュールだったりします。
このときソフトウェア設計者にお願いするのは、スケジュールの中でいついつにソフトウェアが必要になるよというところと、
その設計構想を確保してもらうことですね。
構想の話をお願いした後は、しばらくソフトウェア設計者とは関わることはないです。
メカの構想を進めて、前回話したように電気設計者と協力しながら設計を進めていく。
ある程度進んだところで、再びソフトウェア設計者と話を始める段階になります。
メカ設計者からソフトウェア設計者へ情報を渡します。
一番最初に打ち合わせのときに大体の構想をお話しするんですけれども、
本当にそのときの構想通りに装置ができているかというと、そうでもない場合も多々ありまして、
いろんな検討・レビューを重ねていく中で、最初の構想がちょっと変わっていたりというともあるので、
改めて装置がどんな装置か、どんな動作をするか、どんな制御が必要かという情報を渡す必要があります。
どんなものを具体的に渡すかというと、まずはフローチャートですね。
フローチャートとは、あるプロセスだったり作業手順、アルゴリズムというものを視覚的に表現した図のことを
言うんですけれども、ある動作をさせる装置、さっきのABCという動作があるとすると、
Aの動作をもう少し分解しましょう。Aという動作をもう少し分解していくと、
そのAという動作はあるシリンダーを動作させているとします。
そのシリンダーにエアを送るためのソレノイドをオンさせると、そのAの動作をすると。
そこをもう少し分解していくと、そのAの動作をさせるための前提条件というのがあるんですね。
例えばそのAの他の動作、BとCという動作するものがあるとすると、
そのBとCがどういう状態であるべきかと。
またA自身もどういう位置に、どういう状態にあるかという、
そのAの動作を始めるための前提条件というのをまず定義してあげる必要があります。
どのスイッチがオンしていて、どのスイッチがオフしていないと、
そのAの動作をさせれませんよという前提条件があって、
その前提条件が整っているかというのをまず確認してくださいと。
そこが確認できれば、そのさっきのAの動作をさせるためのソレノイドのナンバーをオンしてくださいと。
そしてそのソレノイドで動作したシリンダーが、
動作したことを確認するためのスイッチがあるとすると、
そのスイッチがオンしたかどうかを確認してくださいと。
それが確認できたら、何秒後に次の動作に進んでください。
もしくは何秒経ってもそのスイッチがオンすることを確認できなければアラームにしてくださいと。
そういう感じで一つ一つ動作を定義していくんですね。
そういうフローチャートをまず作って、
それを全ての動作に対してフローチャートを作ってそれをお渡ししますと。
あとフローチャートだけではなかなか機械の動きが理解しにくかったり、
メカ設計者が作ったフローチャートに間違いがあるという場合も当然可能性としてありますので、
フローチャートだけを元にソフトウェアを作ってもらうと、
間違ったものになってしまう可能性があるので、
実際の動作を表すようなパラパラ漫画のような資料も作りますね。
パワポイントなどでパワポの図形を使って動作を表すこともあるんですけれども、
今は3D CADで設計していますので、
3D CADのモデルを使って各動作の場面の各動作をしているところのコンフィグレーションを作って、
それぞれの各動作の形に合わせたCAD、アセンブリの画面をキャプチャしてパワポに貼って、
それぞれフローチャートの今いる場所に合わせて絵を貼ったり、
それを動画にしたりして、一連の動作というものを理解しやすいようにそういう資料を準備して、
フローチャートと一緒にソフトウェア設計者に渡すということをしています。
それをもとに機械を、装置を動作させるためのプログラムというものを作ってもらいます。
それがラダーで作るのか、NCのプログラムとして作るかというのはソフトウェア設計者にお任せしています。
メカ設計者側から特に指定をすることはしないです。
正直なところ、そこをどう使い分けているかというのは私自身はあまり理解していません。
実際プログラムのデバッグをする段階で、
あそこはラダーの部分だからあの人に言わなきゃダメだとか、
こっちはNC側の方でやっているから、あの人に直してもらわないとダメだというのをデバッグの時に初めて、
そうやっているんだと知るということも多いですね。
そういうフローチャートとかパラパラ漫画のような資料をお渡しして、
何かわからないことがあれば当然質問してきてくれますので、
そういう問い合わせに答えるというところですね。
そういうソフトウェア設計者から質問が来る段階というのは、
メカ設計者がやっている設計というのはとっくに終わっていて、
筆頭も終わっていて、次の別の設計をしている段階だったりするので、
ソフトウェアの設計をしている時にそういう質問が来ても、
あれ何のことだっけと思い出す必要があったりしますねというのはどうでもいいですけれども、
デバッグと出荷のプロセス
その次の段階というのは実機でのデバッグになります。
機械が組み立てられて電源が入って立ち上がった後に、
正しくお渡ししたフローチャート通りに動作させられるかというのを
ソフトウェア設計者と一緒にデバッグをします。
実際の動作はもちろんなんですけれども、
動作中に非常停止ボタンをドンと押して途中で止めてしまった時に、
ちゃんと機械として復旧できるかどうかなど考えられる様々な状況を試して、
お客様が使う状況を再現してバグ出しというものをやっていきます。
デバッグによって問題点や改善点が見つかると、
さっき言ったようにラダーの方はラダーの設計者がやるし、
NC側の方はNCの設計者がプログラムを修正するという感じですね。
再びその修正が終わったものを機械にインストールして、
もう一回試してみて、
直ったねというところで妥当性確認が終わりましたというところで、
お客様に出荷するという流れです。
ということでメカ設計者が考えるソフトウェアのことはこんな感じでしょうか。
今週はここまでです。
ポッドキャストの感想・質問は概要欄にリンクがあります。
Googleフォームからお待ちしております。
各ポッドキャストアプリでの評価もぜひぜひお願いいたします。
ではお疲れ様でした。
ご安全に。