Device Automation のロボットが不安定でよく落ちる

フォローする

Device Automation(DA) を使用したロボットが開発・デバッグ中によく落ちる原因としては以下の理由が考えられます。

開発端末のスペック不足

ロボット開発時とロボット運用時では、ロボット開発時の方が以下の観点からより多くのリソースを消費します。

  • Undo/Redo用の操作履歴のキャッシュへの記録(ソフトを長時間開いておくほどに累積)
  • Design Studio内への画像情報の読み込み(ステップのフローが長くなるほど累積)
  • Device Automationエディターへのリモート端末の画面情報のストリーミング

動作環境としては、32bit 4GBメモリの端末がその対象に入っていますが、同スペックの業務端末を利用してロボットを作成する場合、その他業務アプリケーションやセキュリティソフト、モニタリングソフトなどが同時に稼働する状況ではDesign Studioがリソース不足となってしまいます。

ロボット開発を安定して長時間開発するためには、64bit 8GB以上のスペックを持った端末を開発環境に準備いただくことを推奨します。

また、Device Automation の操作については、専用の端末を別端末としてご用意いただくか、開発機と同居させる際には16GB以上のメモリを搭載した端末のご用意をお勧めします。

 

不要に大きなDAステップを構築している

Design Studio を開くと Device Automation ステップが1つだけ設定してあり、その中で「Excelの読み込み」から「アプリケーションの起動」、「Excelのデータの繰り返し」と「データの投入」までの一連の作業が全て含まれているロボットを時々見かけます。

Device Automatoin はあくまでDesign Studio 上の1ステップにすぎず、1つのステップには1つの機能を実装すべきです。

上記の例で言えば、「Excelの読み込み」「Excelデータの繰り返し」はDesign Studio内のプリセットステップによって実装し、「アプリケーションの起動」、「データの投入」についてそれぞれのDevice Automation ステップにより実装するのが正しい方法となります。

また、「データ投入」部分についてはさらに「データ投入画面への遷移」「データ投入パターンA」「データ投入パターンB」などの機能の意味単にさらにDevice Automation ステップを分割し、それらを個別にSnippet化することにより、デバッグやロボット変更時の柔軟性も確保できます。

Device Automation は Design Studio/RoboServerからそのステップが実行された際、その中に含まれる命令一式をJSON形式のデータとして指定端末(Device)へ送信し、端末内で展開され、実行されます。

この時に大きなDevice Automationステップを作成してしまうことは、呼び出し時の通信負荷、展開時の処理負荷、メモリ容量の圧迫など、必要以上のリソースを端末側で消費し、処理性能に影響を与える原因となります。

該当のポートがファイアウォールでブロックされている

DA端末のポートが開放されていることを確認してください。

[参考]
MCからDAを使用する際は、以下のような流れで通信が行われます。
①DAS→MC Availableになります。 (MCの50080を使用します。)
②MC→DS DASの接続情報をDS/RSに送ります。
③DS→DAS In Useになります。 (DASで設定されたポートを使用します。※下記画像1をご参照ください。)

DAS.jpg
(画像1.DASポート設定画面)

使用ポートが他のアプリケーションや処理とぶつかっている

いくつかのバージョンのDAがインストールされている場合に多い事象ですが、
DASにて設定するポートは一意である必要がございます。
他のバージョンや他のアプリケーションと処理がぶつからないよう、設定を行ってください。

0人中0人がこの記事が役に立ったと言っています

コメント

0件のコメント

ログインしてコメントを残してください。