• 状态
  • 已锁定 已锁定
  • 个回复 4 个回复
  • 名订阅用户 0 名订阅用户
  • 次查看 126 次查看
  • 用户 0 名在线用户
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] SK-AM64B：Codesys EtherCAT 主放大器；通过软运动直接驱动两个伺服电机

admin
Guru**** 1744610 points
Other Parts Discussed in Thread: SK-AM62B, SK-AM64B
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1330077/sk-am64b-codesys-ethercat-master-softmotion-driving-two-servo-motors-directly

器件型号：SK-AM64B
主题中讨论的其他器件：SK-AM62B、

您好、TI 专家！

客户正在评估我们用于驱动两个伺服电机的 AM64器件的性能。

他们应用的 SDK 版本是 SDK9.2 (早期发布的版本、我听说最终的 SDK9.2版本仍在进行中) RT-Linux SDK 默认映像。

它们在 A53内核上的 Codesys 内部运行 EtherCAT 主站和软运动模块、并驱动两个伺服电机、如下所示。

数据路径为：Codesys -> CPSW2G -> A53 ->伺服电机

但是、性能是无法预料的。

最大周期时间达到了1313us、最大抖动达到了227us、如下所示。

由于周期时间和抖动非常高、它会导致 数据帧丢失、伺服 电机最终停止。

我们进行了搜索、了解我们有一些基准测试、例如运行 AM64x EtherCAT 主站作为从站连接到 AM24x、然后驱动伺服电机。  

对于本客户实验、由于客户希望在不使用 AM24x 的情况下实现 AM64x 上的所有功能、因此上述高延迟对驱动伺服电机具有更大的影响。

请问有什么改善性能的建议吗？

我还可以知道即将推出的 SDK9.2最终版本将具有更好的性能吗？

非常感谢！

凯文

  • 0
    TI__Guru**** 1744610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    通过循环测试衡量的中断延迟改进不足以使任何应用实现最佳的实时性能。 9.1从这个角度来看已经很好了。 使用 Codesys 或任何其他实时应用、您将需要进行进一步的特定于应用的调优、并根据您想要优先处理的事项进行选择。 基本 SDK 环境不会被调整为完全优先于其他功能。 我们正在 CoDeSys 的背景下为此编制应用报告、Daolin 将在此处重复采取一些步骤。

    部分本文将在 Embedded World 2024年  4月9日 下午4：00 -下午5：45在 events.weka-fachmedien.de/.../program 上展示。
    第2.3节连接解决方案。

     佩卡

  • 0
    TI__Guru**** 1744610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Kevin：

    Codesys 最近添加了一些全新的方式来尝试和优化 https://content.helpme-codesys.com/en/CODESYS%20Control/_rtsl_performance_optimization_linux.html 的实时性能。我建议首先逐步遵循他们的步骤。

    在 Codesys 更新其性能优化页面之前、根据我尝试的工作、提供了几条初始建议来调整 Codesys EtherCAT 主站的性能。

    1.如果可以减少从 Codesys 运行的任务数、我建议将"ethercat_task"和"visu_task"功能合并为一个任务。 在运行时期间在两个任务之间切换会导致大量抖动。

    2.如果"CodeMeter"许可应用程序(允许在 Codesys 上运行超过30分钟)正在运行，请尝试将 CPU 关联更改为与"EtherCAT_Task"的 CPU 关联相同。  

    3.如果在 SK-AM64B 上运行有任何后台进程，如默认 SDK 映像上的"ti-apps-launcher"或"telnetd"，请禁用这些进程。 一般而言、在瘦 SDK 映像上运行时(使用 SK-AM62B 作为 EtherCAT 控制器时)观察到了更好的整体性能。

    4.为了在运行时使用图形获得更高的性能可见性、而不是任务监视器可以显示的状态、请尝试添加跟踪对象来跟踪当前的循环时间及其高峰时间。 一些说明可在以下位置找到： https://medium.com/@sean.gongz/how-to-get-current-task-actual-cycle-time-in-codesys-267384bcd3b7 

    -道林

  • 0
    TI__Guru**** 1744610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Daolin 和 Pekka：

    感谢您的详细解释！

    客户最近已重试此实验。 他们基于 SDK9.1 RT Linux 完成了以下3项测试。

    1：仅在 AM64x 上运行 Codesys EtherCAT (未连接到 am24x)、伺服电机正常运行。

    2：仅在 AM24x 上运行 Codesys EtherCAT (未连接到 am64x)、 伺服电机正常运行。

    3：在 AM64x 上运行 Codesys EtherCAT 主站、在 AM24x 上运行 EtherCAT 从站。 当周期时间为500us 时、数据帧丢失的可能性很小。

    对于本实验、它们仅运行 EtherCAT、本实验中不使用先前讨论的软运动模块以避免任何冲突。

    您能帮助提供对此方面的任何建议吗？

    此致、

    凯文

  • 0
    TI__Guru**** 1744610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Kevin：

    如我们的 WebEx 聊天中所述、我在配置的周期时间为1ms 时在 AM64x 上观察到了帧丢失。 我还注意到、随着配置的周期时间增加、帧丢失也减少了。 他们选择500us 配置的周期时间是否有特殊原因？

    我建议使用尽可能长的已配置周期时间、默认情况下、Codesys 所设置的时间为4ms、采用此配置时、我记得在17小时的运行过程中没有看到任何帧丢失。 我没有长时间尝试运行1.5ms、但我记得2ms 可能会也可能不会导致帧丢失。

    如果客户尚未调整 Linux 环境(更改调度策略、优先级、禁用不必要的线程等)、我还建议客户尝试尽可能缩短观察到的周期时间、这也可能有助于减少帧丢失。

    -道林