生産設備の制御デバッグって何するの？現役エンジニアが解説【中編】

こんにちはー、りびぃです。

普段は生産設備の業界で、機械、電気、制御およびデバッグ作業の仕事をしています。

本記事は「生産設備の制御デバッグって何するの？現役エンジニアが解説」の中編になります。

まだ前編をご覧になっていない方は、以下のリンクからご覧いただければと思います。

生産設備の制御デバッグって何するの？現役エンジニアが解説【前編】

制御デバッグの進め方(工場出荷前）

5. I/Oチェック

各制御機器からPLCへの信号入力、またはPLCから各制御機器への出力信号が適切に行われるかをチェックする作業になります。

単なる機器の動作確認ではなく「PLCを介して制御できるかの確認である」というのがポイントになります。

パソコンとPLCを繋いだ状態で「実機のセンサをONさせた際にラダー回路上で割り当てたビットがONするかどうか」「PLCから強制的に信号出力させた際に、実機がON（ランプであれば点灯、リレーであればリレーのON）するかどうか」を確認していきます。

このI/Oチェックでは、パソコン上でラダー回路をモニタしつつ実機の操作が必要なことも多いので、制御デバッグのサポートをしてくれる方がもう1人、合計2人以上での作業ができると効率的に実施することができます。

I/Oチェックでは「ハードの組付け（メカ・電気両方を含む）」「本体設定」「通信設定」のいずれか一つでもうまくいかないだけで正常な入出力の確認ができません。

よくあるのが、

• 信号線を端子台へ入れる場所やピンアサインが一つズレていて、想定とは違う入出力が行われていた
• エア配管が逆になっていて、エアシリンダの前進信号を出力すると後退してしまう
• 制御機器の本体設定で、外部端子による制御モードへ切り替えるのを忘れていた
• コネクタの施工に不具合があり、接触不良を起こしていた
• フィールドネットワークのデバイス占有の範囲設定を間違えていた

などです。

不具合発生時には「メカ」「電気」「制御」のどれなのかを原因分析するところからやらなければならないため、制御デバッグの非常に大きな山場の一つです。

「装置がうまく動かない」というのは一見すると制御のバグが原因のように見えるものですが、原因を究明すると実はメカの設計ミス、施工不良だったというケースも非常に多いため、積極的に制御エンジニアへ協力をしてあげることが工期短縮のためのポイントになります。

6. 手動操作による確認

作業員による手動操作にて、機器を動作させられるかを確認していきます。

装置によって操作盤から操作したり、タッチパネルから操作をしたり、その両方の組み合わせだったりなどさまざまですが、最初は各アクチュエータを連動させるなどはせず、機器単体のレベルで動作を確認していきます。

そのことから通称「各個（かっこ）動作」と呼ばれることもあります。

ここで確認するべきポイントは、

• アクチュエータの動作方向およびパラメータが適正かの確認
• インタロックが適切に機能しているかの確認（ソフトリミット用のセンサが検知すると、それ以上モータが動作しないなど）
• アクチュエータが動作する際に、機械部品や配線の干渉がないかの確認

などになります。

この手動操作による確認では、タッチパネル等で操作をしながら、ラダー回路上で信号の状態を確認しつつ、実機にて「正しい動作が行われるか、何か不具合がないか」を同時に確認する必要があります。

なので2～3人以上の人数で確認を行いつつ、何か危険やトラブルを感じたらすぐに非常停止をかける準備をしておきます。

最初はワークなしで動作を確認しますが、問題がなければ試しにワークをラインに入れながらセンサなどで適切に検知可能かを確認していきます。

この際、機器同士の干渉がなかったとしても、ワークと機器との干渉や不具合などが見つかるケースもありますので、気を抜かずに確認作業を進めていきます。

現場でのコミュニケーションを大切に

実は手動操作で装置が動くようになったタイミングで、メカ的な調整作業と混在する機会が増えてきます。

というのもここまでは仮組みのままの状態だったものが、手動操作で機械を動かすことができたり、ワークをハンドリングすることができるようになったタイミングで本格的な調整作業が可能になるからです。

例えば、

• コンベヤ搬送におけるレベル調整
• エアシリンダのメカストッパの位置調整
• カメラや照明の位置や角度の調整

などの作業がこのあたりから始まります。

その際作業の効率化のために、装置内で組立調整をしている最中に、ついつい全く別の個所の動作確認などを進めたくなる気持ちが出てくるのですが、それは絶対にNGです。

そもそも動力がONしている状態で装置内に人が入っている状況というのはとても危険な状態であり、ふとした操作ミス、パラメータの設定ミス、ノイズ、プログラムのバグによる誤動作で人身災害が起こるリスクが高いです（現場によっては、動力ONしている状態で装置内に人が入っている状況が発生した瞬間に工場から退場させられます）。

そのため組立調整が入ってくるフェーズにおいては、

• 装置内に入って作業をする際にはロックアウトを設置するよう声をかける
• 作業干渉が起こらないよう、組立調整の作業者と制御デバッグのエンジニアとで作業進捗や予定を頻繁に確認する
• 仮に装置内に人がいることに気づかずに装置を動かしてしまうことがないよう、動力ONや手動操作で装置を動かす際に「動かします」と声を出す
• 装置内での作業が終わったら、制御エンジニアに「終わりました」と一声かけてもらう

といった現場でのコミュニケーションが非常に重要となります。

制御で難しいのは「動かすこと」ではなく「動かさないこと」

私の経験上、各個操作で機械が動いた瞬間「おー、動いた動いた！」と安心する方が多いです。

ただその一方で「動いたってことは、もうほとんど制御デバッグは終わったようなものだよね？」という発言をする方を、特に制御の仕事についてほとんど理解をしていない方から耳にすることが多いです。

ですが、その認識は大きな間違いです。

この段階では進捗度はせいぜい全体の30%前後でしょう。

実は制御で難しくて確認に時間がかかるのは「動かすこと」よりも「動かさないこと」、つまり「インタロックの確認」なのです。

インタロックとは「特定の条件が満たされない限り、機械や設備が動作しないようにする安全・制御機構」のことを言います。

実際の装置においては、

• モータに対する正転、逆転の出力信号の同時ON
• ワークの有無や位置
• そのアクチュエータの周囲、前後ステーションの機構との位置関係

といった条件で、対象の機構が動作しないよう制限をかけます。

ただ何でもかんでも動作を制限すると、「動くべき条件で動かない」「動きはするが動作速度が制限されているせいでサイクルタイムに間に合わない」などという不都合が生じます。

そのためあらゆるパターンで「想定どおりに動くか、または動かないか」を確認する必要があり、どうしても時間を要するポイントなのです。

なので周りの人は機械が動くようになったことで安心をしている一方、制御エンジニアの頭の中は「本当にこのまま動いて問題ないか？止まるべきタイミングで本当に動きが止まるか？」など、結構ハラハラしながら作業していたりもします。

7. 動作原点の確認

次は動作原点の確認です。

動作原点というのは「自動運転を開始するためのスタートポジション」のことを言います。

一般的に生産設備は、すべてのアクチュエータが動作原点の状態にないと自動運転が起動できないようインタロックを入れています。

なのでまずは手動操作を使いながら、動作原点がONできるかを確認していきます。

動作原点は「装置内にワークがないときの状態でONできるか」という確認だけではなく、サイクル停止時などのように「装置内にワークが残っている状態でもONできるか」という確認も必要です。

装置内にワークが有るか無いかで、動作原点の条件や位置が変わってくることもありますので、その辺りを含めて確認をしていきます。

なお、比較的シンプルな装置および現場のスケジュール次第でこの時点で後述の「自動原点復帰」の確認まですることもありますが、そこはプロジェクト全体の進捗などを考慮しつつ現場でコミュニケーションをとりながら進めるようにしていきます。

8. 自動運転の確認

ここまでのフェーズになると「メカ所掌の作業」「組立所掌の作業」「電気ハード所掌の作業」がほとんど完了し、あとは制御エンジニアの残件を進めていくだけのフェーズになっていきます。

そのためここから先の作業は制御エンジニアの腕次第にもなってくるところです。

では残件が制御マターのみになったところで、続いて実施されるのが「自動運転の確認」です。

エンドユーザさんにて運用されるモードにて、適切に動作するかを確認していきます。

自動運転のラダー回路の作り方にはいくつか手法がありますが、最もよく使われるのが「歩進（ほしん）制御」と呼ばれる手法で、これは「一回の動作」という単位でプログラムの工程を分ける手法です。

例えば「動作A」として「エアシリンダの前進を自動的にさせる」と定義したとすると

• 開始: 動作Aを実行するためのトリガー、フラグ。
• 完了: 動作Aが完了し、次の動作実施を許可するためのトリガー、フラグ。

という構成で基本的にプログラムを組んでいきます。

そうすることで実機でプログラムを実行させた際に、「どこまでの処理がうまくいっているのか」「うまくいっていない処理について、その原因は何か」をしっかり特定していきながら進めるようにします。

なおプロジェクトによっては自動運転モードに複数の種類があり、

• 通常運転
• 空運転
• 段取り運転（段替え）
• 払出し運転
• 一部の処理（カメラの処理など）を無効化して自動運転するモード
• 日常点検モード（マスターワークを使って検査機器が正常であることを確認するモード）

などのモードが存在します。

さらに多品種を扱う生産ラインでは、品種ごとに動作ロジックや動作パラメータが異なることも多いです。

そのうえで「サイクル停止」が入力されて自動運転が一時停止状態になった後、再び自動運転を起動することで作業再開できるかの確認も必要です。

また、自動運転中に作業者による手作業が介在する場合には、そのポカヨケのためのインタロックが適切に働くかの確認も行います。

それらすべてを、このフェーズにて確認をしていきます。

自動運転が始まっても、最初は慎重に

自動運転が始まっても、制御デバッグはまだまだ気が抜けません。

というより、手動運転よりも一層安全に対する意識を高めながら制御デバッグを進めなくてはなりません。

といいますのも、自動運転の最初のうちは装置がどんな挙動を示すか、変に誤動作しないかの確認がとれていないからです。

そのため最初は

• 動作速度を大きく落として動作確認を進める
• 「一回の動作」が完了するごとに中断させながら動作確認を進める

というのが一般的です。

そして少しでも想定外の挙動を示した場合には、すぐに非常停止をかけられるよう常に準備をしておく必要があります。

• 速度を落とした状態で自動運転のロジックが正しいことが確認できていること
• 安全対策を十分に施していること

の2つの条件がそろって初めて、徐々に動作速度を上げながら確認をしていくことが重要です。

傍から見ている側としては「なにをモタモタと装置を動かしているの？もっとテキパキやればいいじゃん！」と感じてしまうかもしれませんが、安全を十分に考慮しながら確認作業を進めているという点をご理解いただけると嬉しいです。

自動運転中は不用意に装置内に入るのは厳禁

制御エンジニアが作業している様子を見ると「装置が停止している状態で、制御エンジニア自身はパソコンでずっとなにかしらの作業をしている」ことが多いです。

これは一見すると「今は動作確認を中断して、別の作業をしている」というように思えますが、実はだんまり運転をしている原因を調査している最中であることも多いのです。

そのため、このタイミングで不用意に装置内に入るのは厳禁です。

もし下手に装置内へ進入すると、

• 不意にセンサが検知した瞬間、突然装置全体が動き出す可能性があるため、非常に危険
• せっかくだんまり運転の原因を調査しているのに、センサ検知等により入出力の条件が変わってしまうので、もう一度状況再現からやり直しになる

という事態になりかねません。

そのため装置内に入る必要がある際は、必ず制御エンジニアの方に許可を取るようにしましょう。