衝突保護機能とも呼ばれるモーションモニタリング機能は、ロボットへの衝突の影響を減らすことができます。現在、主流のロボットは同様の衝突保護機能を備えています。ABBロボットは、この機能を「モーションモニタリング」と呼んでいます。
衝突保護については、ABBロボットの無料機能であり、使用するためのオプションを追加する必要はありません。ただし、ロボットの自動モードと手動のフルスピードモードでのみ機能し、感度は調整できません。オンサイトのプロセス要件に応じて感度を柔軟に調整する必要がある場合、または手動デバッグ中に使用する必要がある場合は、衝突検出ソフトウェアを購入する必要があります。
衝突検出（アクションモニタリング）機能に慣れていない友達は、記事の最後にある公式アカウントに注意を払い、公式アカウントの検索機能を使用して、過去の記事で「アクションモニタリング」を検索し、以前に投稿されたモーションモニタリングに関する記事を見つけることができます。
ABBロボットには、ロボットの力を監視するための2種類の異常アラームがあります。1つは、ロボットが実際に何かにぶつかり、ロボットが行きたがっているが、物にぶつかることを余儀なくされ、移動して警察に電話することができないということです。もう1つは誤った衝突です。ロボットはまだ歩き続けることができるかもしれませんが、リスクを感知したため、積極的に警察に電話をかけ、担当者にリスクを調査するように促します。これら2種類のアラームは本質的に異なるので、見下ろしてみましょう。
本当にヒット
実際のクラッシュアラームの内容を下の図Aに示します。
図Aに示すアラームは、通常、ロボットの動作監視機能がオフになっている（またはオンになっていない）ときに発生します。この種のアラームは、ロボットが非常に大きな移動抵抗を受ける場合にのみトリガーされます。アラームのトリガーには、ロボット器具の損傷、ワークピースの損傷、工具の損傷、さらに深刻な個人的および財産的損失が伴うことがよくあります。したがって、特別なプロセス要件がない場合は、モーションモニタリング機能をオンにすることをお勧めします。ロボットに衝突検出オプションがない場合でも、手動フルスピードモードと自動モードでロボットを保護できます。
偽のバンプ
誤衝突は「動き監視保護」であり、衝突を回避するためにロボットがとる自己保護手段です。誤った衝突にはさらに多くの理由があり、これが今回の共有の重要な部分です。誤衝突アラームの内容は図Bのとおりです。
もう1つ説明があります。マニュアルをよく読む友人は、マニュアル全体に「arg」という単語がたくさんあることに気付いたはずですが、同じ顔が異なるマニュアルの異なる位置に表示される可能性があります。実際、これは英語の単語引数[ˈɑːɡjumənt]の省略形であり、マニュアルの不確実な値を置き換えます。たとえば、上の図のアクションモニタリングのアラームは、軸1のアラームまたは軸2のアラームにすることができます。また、軸3と軸4のアラームになることもあります。マニュアルのこの説明は、マニュアルをより簡潔かつ厳密にするために、特定の側面を説明するだけでなく、すべての状況を個別に説明するのではなく、すべての可能性に対処するためのものです。
トピックに戻ると、ロボットの動きの監視がアラームをトリガーしてシャットダウンすることが何度もあります。現場の担当者が調査に行ったとき、衝突は見られませんでした。衝突の疑いも見られませんでした。「オオカミがやってくる」ということが何度も起こりました。物語。表面的にはロボットは「ばかげている」が、問題なく警察に通報する。（同様の問題は多くの人から苦情が寄せられたに違いないと思います。）しかし、ほとんどの場合、このような問題は、機器の初期設計または後期デバッグと構成の過程での技術者による「不合理な操作」によって引き起こされます。以下の考えられる理由を分析してみましょう。
外力による
外力は、モーションモニタリングをトリガーする最も単純で直接的な理由です。この理由は、現場でのトラブルシューティングでも最も簡単に見つけることができます。一般的な理由には、ロボットと周辺機器の間の干渉、一部のアクションでのロボットフィクスチャとロボット本体の間の干渉、および自分で作成したパイプラインパッケージがロボットの特定の姿勢に干渉することが含まれます。特定の技術的機会のために設計された特別なパイプラインパッケージまたはフィクスチャの場合、互換性のあるロボットが達成できるすべての姿勢を実際に達成できない場合は、「バレル効果」の原則に従ってロボットの活動の制限を見つける必要がありますショートボードの範囲を制限し、ショートボードの項目に従ってロボットをロボットに設定して、ロボットの単軸の動作範囲を制限します。これにより、一部のロボットのクリティカルポスチャの後半がパイプラインパッケージまたはツールの摩耗や破損を引き起こさないようにし、これらの理由による損傷を防ぎます。その結果、ロボットの動作監視が誤ってトリガーされます。
ロボットの軸制限設定に慣れていない友達は、記事の最後にある公式アカウントをフォローし、公式アカウントの検索機能を使用して過去の記事の「制限」を検索できます。また、軸制限設定に関する以前に公開された記事を見つけることができます。
モーションモニタリングの感度調整が小さすぎる
これは実際には非常に簡単です。モーションモニタリングの感度を適切に上げるだけです。衝突検出（アクションモニタリング）機能に慣れていない友達は、記事の最後にある公式アカウントに注意を払い、公式アカウントの検索機能を使用して、過去の記事で「アクションモニタリング」を検索し、以前に投稿されたモーションモニタリングに関する記事を見つけることができます。ただし、感度が最大値に調整されている場合、またはロボットに衝突検出オプションがなく、モーションモニタリングを直接オフにしたくない場合は、下を向いてください。
ツールデータの定義が正しくありません
ツールデータ（tooldata）は、ツール（溶接トーチ、固定具など）の特性を説明するために使用されます。これは、手首に何が取り付けられているかをロボットに知らせるデータです。これらのデータには、ツールTCP（Tool Center Pointer）の場所の物理的特性とツールの負荷が含まれます。ロボットの実際の物理的位置は、TCPと座標系の計算によってロボットによって取得されることがわかっています。異なるTCPと座標系の組み合わせによって得られる計算結果は異なるため、得られるロボットの動作結果も異なります。正確なTCPを確立することは、私たちのプログラミングスクールの基礎です。しかし、Tooldataのもう1つの重要なデータであるtload（ツールロード）は、私たちが見落としがちです。Tloadはロボットのプログラミング位置とは関係ありませんが、重量や中心などのツールの物理的特性を表すことができます。たとえば、負荷が10kgのIRB 1600ロボットの場合、重量が2kgの工具と重量が5kgの工具を保持した後に耐えることができる余分なワークピースの重量は明らかに異なります。さらに、それらの間の関係は単純な線形関係ではなく、ロボットの負荷特性曲線はしばしば非常に複雑です。オンサイトデバッグ中に、データのデフォルト値を使用すると、ロボットはその時点でエラーを報告しませんが、ロボットの実際の負荷がより大きいため、ロボットが後のデバッグプロセス中にアクションモニタリングアラームを誤って報告する可能性が大幅に高くなります。ロボットにはもっと計画があります。
構造がより複雑で中心が確認しにくいツールの場合、ABBロボットシステムに付属のLoadIdentify（負荷測定サービスルーチン）を使用して、ロボットがそれを計算して取得できるようにすることができます。
ペイロードが正しくありません
ペイロード（loaddata）は、ロボットフィクスチャによって適用されるペイロードを表すために使用され、上記のツールデータの一部でもあります。一般的に、ワークの重量が小さい、またはワークが直接ないアプリケーションシナリオ（溶接など）では、負荷データが特に設定されていなくても、ロボットの使用に大きな影響はありませんが、ワークが重いアプリケーションでは影響が大きくなります。処理やパレタイズなどのシナリオでは、loaddataの設定が正しくないと、ロボットの動作監視が誤ってトリガーされる可能性があります。ペイロードの設定が正しくないと、ロボットパスの精度など、ロボットのパフォーマンスにも影響します。
製品の種類が多く、ワークの重量に大きな違いがあるアプリケーションシナリオでは、GripLoad命令を使用して、Rapidプログラムを実行しているプログラム中に、ロボットのロードデータを自動的にロード、アンロード、または切り替えることができます。このようなタイムリーで正確なロボットのペイロードの修正により、次のことができます。ロボットのパフォーマンスを最大化するために、ロボットを最良の方法で動かします。
不当な加速設定
ニュートンの第2法則式F = m * a（力=質量*加速度）の分析から、ロボットの質量と負荷の質量が決定され、一定であることがわかり、それは定量値です。次に、運動中のロボットに必要な力（モーター回転に必要な力は、ロボットの加速度と正の関係があります。つまり、ロボットの加速度が大きいほど、モーターが出力する必要のあるトルクが大きくなります。特にロボットのペイロード質量（m）が特に大きい場合、この現象はより明白になります。したがって、ロボットにモーションモニタリングアラームがある場合、以前の対策を講じると問題は解決できず、ロボットの生産サイクル要件はそれほど高くないので、ロボットの加速度を適切に減らす方法でもあります。
ロボットの加速設定に慣れていない友達は、記事の最後にある公式アカウントに注意を払い、公式アカウントの検索機能を使用して、過去の記事で「加速」を検索し、加速設定に関する前の記事を見つけることができます。
ロボットモデルは小さい
上記の対策を講じた後も、アクションモニタリングが誤って報告される場合は、ロボットモデルが適切に選択されておらず、負荷が小さすぎる可能性があります。この場合、妥協は、ロボットを交換せずにプロセス要件を考慮に入れることに基づいてのみ行うことができます。たとえば、生産サイクルを適切に減らし（ロボットの加速を減らし）、ロボットTCPの長さを短くし、ロボットツールの品質を下げます。しかし、実際には、このような状況になる可能性はまだ比較的低いです。ロボットを選択するとき、設計エンジニアは、負荷重量中心とABBが提供する対応するロボットの位置との関係を参照して選択します。ただし、計算エラーは除外されません。実際、ABBには、この側面のためにRobotLoadと呼ばれる小さなソフトウェアがあります。これは、設計者がプロセス要件に従ってロボットモデルを選択し、既存のソリューションの合理性を検証するのを支援するために使用されます。
RobotLoadソフトウェアは、記事の最後にある公式アカウントに注意を向けることができます。公式アカウントの検索機能を使用して、過去の記事のLoadを検索し、RobotLoadの使用とダウンロードに関する記事を検索します。
PS：
記事の障害情報クエリのスクリーンショットは、「障害クエリ」アップルトからのものです。このソフトウェアを必要とする友人は、公式アカウントのメニューバーでアップルトエントリを見つけることができます。
この共有はここにあります。この記事が役に立った、または刺激を受けた場合は、かわいい小さな手を動かして読んだり、友達の輪に転送したりして、より多くの人々に刺激を与えましょう。
自動化された生産の家の最初の記事
