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.

[参考译文] IND-COMMS-SDK:EtherCAT 循环输入数据三路缓冲似乎已损坏

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1421481/ind-comms-sdk-ethercat-cyclic-input-data-triple-buffering-appears-to-be-broken

器件型号:IND-COMMS-SDK

工具与软件:

尊敬的 TI 团队:

在 AM64x EtherCAT 子器件处理输入(子器件->主器件)数据三缓冲的方式方面、我们遇到了一个相当严重的问题。

我们首先在定制应用程序中遇到该问题、但也可以通过"Beckhoff"子器件示例重现该问题。

  • 工业通信 SDK 09.02.00.08
  • AM64x EVM 上的 EtherCAT_SLAVE_Beckhoff_SSC_DEMO (修订版 C、SR2.0硬件)
  • 10ms EtherCAT 主器件周期
  • 通过0x1c32.1/0x1c33.1将 EtherCAT 子器件配置为自由运行模式

当配置为自由运行模式时、PDO_InputMapping 从 MainLoop 调用、并且在我的测试期间每~10-16us 更新一次输入。

PDO_InputMapping 调用 HW_EscWriteIsr 将循环输入写入 ESC 存储器。 在 HW_EscWriteIsr 中调用 BSP_GET_PROCESSOR_DATA_ADDRESS 来获取"当前"三路缓冲区的实际偏移。

我希望更新在2 (还是3?)之间迭代 向三个缓冲区中写入、但使用我的日志记录(开销极低~、记录到 DDR 存储器中的环形缓冲区)、我可以看到、对一个地址连续写入~600次(在本例中为0x140e)、然后~600次写入下一个地址(0x1407)、然后~600次写入下一个地址(同样为0x140e)、依此类推。 缓冲区切换之间的时间几乎正好是10ms、即每次 EtherCAT 帧读取 SyncManager 时、PDI 将在下次调用 bsp_get_process_data_address 时获取不同的缓冲区。

附件是带有我们的日志记录的 CSV 文件。 子器件示例只修改为在 HW_EscWriteIsr 中包含我们的记录工具和日志输出:

void HW_EscWriteIsr(uint8_t *pData, uint16_t Address, uint16_t Len)
{
    int16_t sm_index;
    uint16_t ActualAddr = bsp_get_process_data_address(pruIcss1Handle, Address, Len,
                          &sm_index);

    LOGGERBUF_LOG3(main, 0x1, "HW_EscWriteIsr", Address, Len, ActualAddr);

在记录中、"R5F"和"tsdiff"通过 ts 周期计数器(800 MHz)测量。 上述记录仪中的参数("Address"、"Len"和"ActualAddr")以十六进制和十进制格式打印。 您可以看到、从开始 PDO_InputMapping 就一直在0x140e 处写入缓冲区、直到~600在该缓冲区切换到0x1400时更新。 这些~600次更新的持续时间也是~10ms。

这种三角缓冲行为是有问题的、因为如果子设备持续更新同一缓冲区、则子设备无法将最新的数据传送到网络。 这也是我们首先注意到这个问题的原因:

  • 自由运行的子器件以 EtherCAT 周期~13倍的速度更新循环输入数据
  • 每次更新都会在输入数据中存储一个递增计数器
  • 每个 EtherCAT 周期通常会显示计数器递增13或14 (周期为异步)、但每隔一段时间(例如、3000000 ~80 of 3000000)、计数器就不会在两个 EtherCAT 周期之间递增、即我们收到相同的循环输入数据两次。
  • 这意味着我们得到的输入数据更新不会稍微有点旧(计数器将是+11或+12而不是+13/+14进行输入数据更新)、但我们得到的输入数据是整个 EtherCAT 周期之前的数据(之前为13或14次循环输入数据更新)

我将 EtherCAT 子设备固件在09.02.00.08和09.02.00.15之间进行了比较、这些固件是相同的、因此我希望.15中不会针对此问题进行任何修复。 通信 SDK。

我们不知道这个问题是否也出现在旧版本中,我们只是刚刚注意到它。

在"正常"SM 同步操作期间、您不会直接注意到这个问题、因为在这种情况下、每次输入数据更新都会有一个帧。

此致、

Dominic

e2e.ti.com/.../ethercat_5F00_slave_5F00_sm3_5F00_address_5F00_beginning.zip

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [quote userid="387520" url="~/support/processors-group/processors/f/processors-forum/1421481/ind-comms-sdk-ethercat-cyclic-input-data-triple-buffering-appears-to-be-broken 10ms EtherCAT 主设备周期

    你好、Dominic

    您是否在较低的周期时间(例如50或100us)看到类似的行为?

    此致

    Pratheesh

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

    您好、Pratheesh:

    不确定您所问的问题。 我想您说的是输入数据更新速率较低、例如每50us 更新一次、或每100us 更新一次、而不是每~10-16us 更新一次、对吗?

    在客户应用中、当它运行直流同步时、我们遇到了这样一个情况:

    主器件(网络)周期和子器件输入周期(不完全是 Sync0、而是基于 DC 的器件本地时钟)、运行时间为1ms。 "通常"您会在每个网络周期得到一个输入更新、但由于主器件抖动、有时我们有两个输入更新周期、中间没有网络周期。 在本例中、我们看到相同的三缓冲器地址两次。 这基本上是相同错误的症状、但在这种情况下、您很少看到它、因为每个网络周期通常有一个输入更新。

    如果您说的网络周期要快得多、例如50/100us 而不是10ms:我们也测试了1ms 的网络周期。 我将看到此设置的速度快得多、但这是一个更通用的主器件设置、并不侧重于非常短的周期时间。

    我想测试的另一件事是返回的数据有多"最近"。 也就是说、如果我开始在循环数据中放置计数器、网络上看到的第一个计数器值将是什么。

    此致、

    Dominic

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

    小更新:

    • 我已向 APPL_InputMapping 添加了延迟、以便输入数据在150us (而不是~10-15us)或更长时间发生更新、并具有相同的结果。
    • 我已经捕获了 EtherCAT 帧、从子器件返回到 SAFEOP (帧#91)的第一个数据全部为零、即使我现在正在写入计数器、从0x1开始。
    • 返回的第二个循环数据(帧#94)包括从缓冲区0x140e 切换到缓冲区0x1400之前紧接着写入 APPL_InputMapping 中的计数。

    我已经附加了 pcap 跟踪和自己的日志记录(arg4是我的计数器、arg5是0x55aa 的固定值)。

    由于在 StartInputHandler 中首先调用 PDO_InputMapping、我认为第一个帧应该已经包含有效数据、而不是零。

    此致、

    Dominic

    e2e.ti.com/.../ethercat_5F00_slave_5F00_counter.zip

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

    另一个更新:

    我们还认为、因此返回的循环数据始终落后一个周期。 在 pcap 布线中、可以看到在83号帧中从器件被请求进入 SAFEOP。 ~7.6ms 后(时间戳不是很准确)、第一个循环帧出现在第91帧中。 如果我们从日志记录中查看时间戳、从第一个 PDO_InputMapping (大概是由于切换到 SAFEOP 而从 StartInputHandler 调用的)到三缓冲区的第一个开关(0x140e -> 0x1400)需要~7.2ms (560万个周期)。 缓冲区0x140e 最后一次写入计数器0x28、该计数器只能在第94帧中看到、之后可能是4ms (更有可能是5ms、我的周期时间)。

    • 有人能确认我们的理解、这不是三重缓冲的预期行为吗? 我们假设 PDI 应交替写入两个(或三个?)中的一个 缓冲区、因此网络上的帧可能总是接收到最新数据。
    • 这是已知问题吗?
    • 这是一个回归,还是总是被打破了?

    此致、

    Dominic

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

    另一项更新:

    我看到09.02.00.15存在同样的问题。

    此致、

    Dominic

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

    ...和相同的行为08.06.00.45。 我不打算检查任何早期版本。

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

    您好、Dominic:

    请期待 EOD 明天回复。 同时、我将介绍所提供的 thread 和 pcap 文件。

    此致、
    亚伦

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

    您好!

    我想简单地补充一点、我还注意到以下设置中存在类似的行为:

    • 在 AM64x 上运行 EtherCAT 从站工业通信 SDK 09.01.00.03的简单演示
      • 我已修改 堆栈 、以将接收到的过程数据发送回主器件
      • 在 SyncManager2同步模式下运行(也可以在具有特定设置的分布式时钟模式下运行)
    • PLC 作为主设备运行 Codesys  
      • 在每个 EtherCAT 周期上将处理数据递增1
      • 确定发送的过程数据和接收的过程数据之间的差值
    • 使用100µs 和1000µs 的 EtherCAT 周期时间进行测试

    在大多数 EtherCAT 周期中、确定的差值为1、 正如我所预期的那样。 但在相当多的周期中、差异大于1。 由此我得出的结论是、从器件中的过程数据并不总是最新的。

    此致、
    Jonas

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [报价 userid="387520" url="~/support/processors-group/processors/f/processors-forum/1421481/ind-comms-sdk-ethercat-cyclic-input-data-triple-buffering-appears-to-be-broken/5447702 #5447702"]
    • 有人能确认我们的理解、这不是三重缓冲的预期行为吗? 我们假设 PDI 应交替写入两个(或三个?)中的一个 缓冲区、因此网络上的帧可能总是接收到最新数据。
    • 这是已知问题吗?
    • 这是一个回归,还是总是被打破了?
    [报价]

    这始终是这种情况、并且与 TxPDO IIRC 的 ET1100行为相匹配、因为 MainDevice 在 DC 模式下在下的下一个 Sync0上拾取数据

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/784264/rtos-processor-sdk-am335x-ethercat-communication-latency---loopback-test/2903185#2903185

    这一切都是假设从器件在直流模式下运行的。 1ms 周期时间内获得的读数是多少

    1) PLC 到 SDevice ->~0.3周期(Rx PDO)

    2) SDevice 到 PLC ->~1.7周期(Tx PDO)

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

    您好、Pratheesh:

    我不确定您的回复与我们的问题有何关系。

    关于 Jonas 提到的问题(与我们的项目无关)以及我对数据总是"太旧"的担忧:我们将在客户应用程序上验证该问题。 从我运行的测试中、我认为数据必须"落后一个周期"、但这不是主要问题。

    主要问题是、如果我们重复写入相同的缓冲区地址、三重缓冲可能无法正常工作。

    我相信我已经毫无疑问地验证了 TI Beckhoff 从站示例正在不断写入同一个缓冲区地址、而且我相信我们可以同意这种行为是错误的。

    :您是否能够验证我们的调查结果?

    此致、

    Dominic

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

    您好、Dominic:

    您是否能够验证我们的调查结果?
    • 还没有。 我会在下周结束前查看并与您联系。

    此致、
    亚伦

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

    你好、亚伦、
    您好、Pratheesh:

    我在 SM 同步模式下运行了另一个测试。 在这种情况下似乎没有问题。 我将把一个输出字节环回到一个输入字节。 在网络布线中、我可以看到输入在输出变为高电平一帧后变为高电平。

    我还在直流模式下运行了几个测试。 通常情况下这没问题、但当网络上的帧抖动过大时、我会遇到类似的问题。

    在一个测试用例中、我人为地将主器件发送帧延迟了150us (1ms 周期时间)。 我在 HW_EscWriteIsr 中看到了同一个缓冲区地址两次。 我不认为这应该是合法发生的。

    在另一个测试案例中、我人为地将主器件发送帧延迟了1200us (1ms 周期时间)。 在这种情况下、我也看到过两次相同的缓冲区地址、但当延迟帧到达子器件时、我也没有从 APPL_InputMapping 中获取最新数据:

    • 到帧#20094的之前周期没有问题
      • 子器件配置为输入同步、因此 Sync0在帧之前触发(我在 PDI ISR 之前见 Sync0 ISR ~110us)
      • 在第20094帧处、从子器件接收计数器0x266c
    • 帧#20095延迟~1.2ms、接着立即延迟 #20096
      • Sync0在 idx 48928和48933下触发两次、其间没有帧
        • 在 idx 48932处、HW_EscWriteIsr 将计数器0x266d 写入0x1400的三路缓冲器
        • 在 idx 48936上(999us 之后)、HW_EscWriteIsr 将计数器0x266e 写入0x1407处的三重缓冲器
      • 延迟帧的 PDI ISR 可以在 HW_EscWriteIsr 之后的 idx 48936和 idx 48939 (~311us)位置看到
    • 当#20097和#20098帧到达主器件时、它们都可以看到先前~1.3ms 写入的计数器0x266d
    • 当主器件接收到第20100帧时、会承载计数器0x266f
    • 当主器件接收到第20102帧时、它承载计数器0x2670

    当调用 HW_EscWriteIsr 并在帧前~300us 更新数据时、子设备返回#20097和#20098帧中的过时数据是不合法的。

    这当然是人为造成的、但主器件可能抖动或帧丢失。 这可能导致直流同步子器件向输入缓冲器写入两次、我希望返回最新数据。 这似乎不是真的。

    我认为直流模式和自由运行问题是我最初报告的相关问题。 当输入缓冲器被写入两次而其间没有帧时、似乎存在问题、这是自由运行模式下的默认行为、但在直流模式下当然也可能发生。

    如果您有关于测试设置和布线的问题、请告诉我。

    此致、

    Dominic

    e2e.ti.com/.../ethercat_5F00_slave_5F00_loopback_5F00_dc_5F00_input_5F00_1200_5F00_09020015.zip

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

    你好、Dominic

    感谢对场景的详细说明。 我们了解了固件和驱动程序接口、发现了潜在的问题。

    在 HW_EscWriteIsr ind-comms-sdk/source/industrial_comms/ethercat_slave/Beckhoff_stack/stack_hal/commchw.c·(  位于 main TexasInstruments/ind-comms-sdk·(github.com))中  、您可以尝试注释出 bsp_process_data_access_complete-comms-sdk/source/industrial_comms/industrial_comms/host_lock_slot_sp_state_state.c (位于)的 bcat_slave_state_state_state_sdk_state_state_sdk_strap 配置、以完成对 github.com 中的 bss_strap 配置。 似乎此状态阻止固件中的缓冲区指针交换。 由于 写入和读取 API 均共享用于测试的 BSP_PROCESSOR_DATA_ACCESS_COMPLETE -请将更新后的版本直接复制到 HW_EscWriteIsr。 请告诉我这是否有帮助。

    此致

    Pratheesh

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

    您好、Pratheesh:

    感谢您的参与。 我会尝试一下、但我还不是很相信。 如果不是通过 BSP_PROCESSOR_DATA_ACCESS_COMPLETE 来更新 SM、那么子器件固件应如何检测 PDI 更新了 SM?

    "正常"ESC 会检测到对 SM 最后一个字节的写入、但这显然不属于 PRU 实施的问题。

    我也不能完全确定您的意思是什么:

    由于  bsp_process_data_access_complete 由写入和读取 API 同时共享以供测试-请将更新的版本直接复制到 HW_EscWriteIsr。

    我想您只需要我注释掉对 bsp_process_data_access_complete 的调用、如下所示:

    HW_EscWriteIsr 只由 PDO_InputMapping 调用、BSP_PROCESSOR_DATA_ACCESS_COMPLETE 不做任何操作、除了写入 LOCK_PD_BUF_HOST_ACCESS_FINISH (+一些健全性检查)。

    我稍后会在办公室测试。

    此致、

    Dominic

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

    您好、Pratheesh:

    在 HW_EscWriteIsr 中注释掉了 bsp_process_data_access_complete、我不再从子器件获得任何返回的输入。 我可以看到、在 DC 同步设置中、PDI 不断写入0x140e 处的缓冲区、但显然网络中从未返回缓冲区。

    我不知道我是否误解了你希望我改变的东西。 如果这是预期的更改、您可以联系我、那会很好。

    此致、

    Dominic

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

    你好、Dominic

    好的。 在这种情况下、可能需要更改固件。 我们很快就会回来讨论这个问题。

    此致

    Pratheesh

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

    您好、Pratheesh:

    是否有关于该主题的任何新闻或确认?

    我们认为、etherCAT freerun 模式不能与现有固件一起使用。

    是这样吗?

    BR

    Armin

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

    尊敬的 Armin:

    我们正在调查在 FreeRun 模式(使用 TwinCAT)下启动循环数据期间遇到的过程数据地址问题。 将保持发布在相同位置。

    此致、
    亚伦

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

    Dominic,Armin,

    根据当前状态关闭该线程。

    此致、
    亚伦

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

    大家好、Aaron 和 Pratheesh:

    非常感谢您提供修复的 etherCAT FW。  

    Freerun 模式现在似乎工作完美。  

    请添加一条有关固定 etherCAT 固件的官方可用性的说明。

    BR

    Armin

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

    你好、亚伦、

    在大多数 EtherCAT 周期中、确定的差异为1、 正如我所预期的那样。 但在相当多的周期中、差异大于1。 由此我得出的结论是、从器件中的过程数据并不总是最新的。

    关于 上面文章中描述的我的测试:只有 Freerun 模式受此问题的影响、还是 SM2同步模式也会受到影响?

    此致、
    Jonas

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

    为提供概述、该问题是由于固件中交换相关代码的不匹配造成的。 此问题将在下一个工业通信 SDK 版本(v10.0)中修复。

    此致、
    亚伦

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

    您好、Jonas:

    此修复似乎也适用于您所面临的问题。 建议为您的查询创建一个新的 E2E 主题。

    此致、
    亚伦  

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

    大家好、Aaron:

    建议为您的查询创建新的 E2E 主题帖。

    我已打开一个新主题:

    IND-COMMS-SDK:EtherCAT 循环处理数据缓冲区不一致-处理器论坛-处理器- TI E2E 支持论坛

    此致、
    Jonas