パフォーマンス
計算には CPU 負荷がかかるため、動作の計画は別のタスクで実行されます。この別のタスクは計画タスクと呼ばれ、バス タスクと並行して実行されます。PLC のパフォーマンスが、バス タスクに間に合うように計画タスクでパスを計画するのに十分でない場合、パフォーマンスの問題が発生します。
動作計画におけるパフォーマンスの問題は、 SMC_CP_QUEUE_UNDERRUN エラーが発生するだけでなく、動きがぎくしゃくしたり、予想よりも遅くなったりすることもあります。 SMC_CP_QUEUE_UNDERRUN エラーについては、 よくあるエラー 章。動作に関するパフォーマンス関連の問題の診断については、以下で説明します。
動きが遅い、またはぎくしゃくしている場合の診断
パフォーマンス上の問題がない場合、各動作は、少なくとも1つの 有効限度 は、動作全体を通して到達されます。例として、X 軸と Y 軸の 2 つの単純な 2 次元ガントリーと、位置 (0,0) から (10,-10) への PTP 動作を考えます。最大軸速度は 20、最大軸加速度は 100、最大軸ジャークは 1000 です。
予想される動きは次のようになります。
最初に最大ジャークで加速が確立され、加速制限値 100 に達します。一定加速の短いフェーズの後、最大ジャークで再び加速が低減され、加速度 0 で速度制限値 20 に達します。一定速度のフェーズの後、減速が行われ、速度と加速度 0 で目標位置に到達します。
実際の動きがこの理想的な曲線から逸脱する理由は 2 つ考えられます。
計画タスクのパフォーマンスの問題により、計画された動きは理想的な曲線と一致しません。
計画された動きは理想的な曲線に対応していますが、ロボットはそれを期待どおりに実行しません。
ケース1: 計画タスクのパフォーマンスの問題
計画中にパフォーマンスに問題がある場合は、代わりに次の動きになる場合があります。
これは、バス タスクの実行と並行して、計画タスクで移動が計画されるためです。平均すると、計画タスクはバス タスクに必要なだけの軌道を提供する必要があります。パフォーマンスがこれに十分でない場合、移動は遅くなります。これにより、波状の速度曲線が発生します。
このような問題を診断するための最初の、そして最も重要なツールはトレースです。 fSetPosition、 fSetVelocity、 そして fSetAcceleration 各軸の変数は、 numTimeBudgetExceeded そして numSlowDownLowIpoQueue の出力 SMC_GroupReadPlanningStatistics 機能ブロックも記録する必要があります。これらのカウンターが継続的に増加する場合は、パフォーマンスに問題があります。
注記
同様に fSetPosition、 fSetVelocity、 そして fSetAcceleration 変数には、 fSetJerk ジャークの変数。ジャークはバスタスクサイクル中に適用される平均ジャークではなく（よく予想されるように）、サイクルの終わりの瞬間ジャークであることに注意する必要があります。したがって、 FSetJerk パフォーマンスの問題を診断する上での重要性は限られています。
動きを改善する方法
次のリストには、パフォーマンスの問題を処理する手順が含まれています。
速度、加速度、ジャークの制限値の調整:
現在の速度から停止まで減速するのにかかる時間が長くなるほど、必要な計算能力は大きくなります。
したがって、速度の有効制限値が高く、加速度とジャークの有効制限値が低いと、パフォーマンスの問題が発生する可能性が高くなります。
特に、加速度とジャークの制限値は不必要に低く設定すべきではない。
計画タスクの優先度を上げるか、計画タスクをブロックしている他のタスクの優先度を下げます。計画タスクは、バス タスクに次いで 2 番目に高い優先度にする必要があります。
複数のCPUコアが利用可能な場合は、計画タスクを専用コアに割り当てます（計画タスクの構成）。
使用
SMC_TuneCPKernel価値を高めるためにfPlanningIntervalおよび/またはfSyncBufferDuration計画パラメータ。の
fPlanningIntervalパラメータは、計画の最大増分（秒単位）を指定します。計画タスクのサイクルタイムは、この値を永続的に超えてはいけません。値を大きくすると計算能力が低下しますが、速度、加速度、ジャークの設定された制限値が完全に利用されない可能性もあります。開始値0.016秒（ CODESYS SoftMotion バージョン 4.6.0.0 以降では、パフォーマンスが許容できるレベルになるまで値を徐々に増やしていく必要があります。の
fSyncBufferDurationパラメータは、計画タスクとバス タスク間のバッファのサイズを指定します。計画タスクのピーク サイクル タイムは、この値を超えてはなりません。値を大きくすると、計画タスクのサイクル タイムのピークを補正できます。ただし、同時に、割り込みの実行と動作の中止の待ち時間も長くなります。
ケース2: ロボットが計画された動きに期待通りに従わない
ロボットが計画された動きに期待どおりに従わない場合は、次の理由が考えられます。
コントローラのリアルタイム機能が不十分
ドライブの制御ループの問題
リアルタイム非対応のコントローラでは、 CODESYS Control Win、または基盤となる Linux システムのリアルタイム パッチが適用されていない Linux ベースのコントローラーでは、十分なパフォーマンスがあっても、動作が遅すぎたり、ぎくしゃくしたりすることがあります。これは、バス タスクが設定された時間枠内で時間どおりに実行されない場合に発生します。
動きを改善する方法
タスク設定の「監視」タブ 1バスタスクのタスクジッターをチェックする 2 高すぎます。これは、バス タスクが同等またはより高い優先度のタスクに置き換えられているか、コントローラが十分なリアルタイム機能を備えていないことが原因である可能性があります。
ジッターが高すぎて、バス タスクの優先度が最高であることがすでに確認されている場合は、コントローラーのリアルタイム機能が不十分です。この場合は、リアルタイム特性が優れたコントローラーを使用してください。
ドライブに制御ループの問題がある場合は、制御ループ パラメータを調整する必要があります。トルク フィード フォワード制御によって、制御ループのパフォーマンスを向上させることもできます。
詳細については、以下を参照してください。 トルク制限とトルクフィードフォワード制御
1: アプリケーションの起動後の最初の PLC サイクルでは、期間が長くなり、ジッターが増加することが多いため、コンテキスト メニューでタスク監視の測定値をリセットすることをお勧めします。
2: ジッター値が約 20 マイクロ秒までであれば非常に良好で、約 100 マイクロ秒までであれば良好です。使用するドライブによっては、より高いジッター値での動作も可能な場合があります。ジッター値がバス タスクのタスク間隔の桁に達すると、上記のエラー パターンが発生する可能性があります。