请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
器件型号： AM2432
问题
我们目前正在研究 DLR 一致性 (ODVA CT22)、我们有关于 Sign_On 溢出方案（特别是单播连续 Sign_On 帧）的正确处理的问题。
背景
在执行期间：
- CT22 DLR 仿真测试 2.3：
Sign_On 帧–溢出
我们的 DUT 在以下情况下失败：
- 分析 Sign_On 单播结果
根据测试结果：
“观察到序列 ID 0x15 的 1 个 Sign_on 帧；预计至少 2 个 Sign_on 帧“
观察到的行为
从数据包捕获：
- CT 工具首先发送 超过最大大小 （~1512 字节）的多播 Sign_On 帧。
- 然后、它 向 DUT（~60 字节）发送单播 Sign_On 帧（连续 Sign_On）。
- 但是、DUT 不传输任何响应帧。
当前的实施问题
从我们对 TI SDK (EIP_processProtocolFrames) 的分析可以看出、DLR 帧检测是根据以下标准执行的：
Destination MAC == 01:21:6C:00:00:02 (DLR multicast)
因此：
- 单播 Sign_On（连续 Sign_On）帧 不被识别为 DLR 帧
- 这些帧 在 EIP_processProtocolFrames() 中被丢弃
CIP 规范参考
根据 CIP 规范第 2 卷第 9-5.5.4 节（Sign_On 工艺）：
-
当 Sign_On 帧超过最大大小时：
- 节点 不附加其地址
- 相反、它会 将 Sign_On 帧直接发送到活动监控器（单播）
-
收到此单播 Sign_On 后：
- 主管 重新启动 Sign_On 进程
- 它 直接向节点发送新的 Sign_On 帧（单播）
- 节点应：
- 添加其地址
- 再次转发 Sign_On 帧（多播）
这意味着 必须将单播 Sign_On 帧处理为有效的 DLR 帧、而不是丢弃。
问题
我们尝试了以下修改、测试通过、但我们不相信这些是正确的实现。
(1) DLR 帧检测
我们修改了代码、以便：
- 单播 Sign_On 帧也由处理
EIP_DLR_processDLRFrame()
问题： 在这种情况下、识别 DLR 帧的正确方法是什么？
是否有任何推荐的方法（例如 EtherType、DLR 帧类型）？
(2) 目标 MAC 处理
为避免 CT 故障：
- 在转发之前、我们将目的 MAC 地址修改为 DLR 多播地址
问题： 将目的 MAC 地址重写为多播是否具有正确的行为？
或者是否应保留原始单播目的地？
(3) signOnRcvdFlag 处理
在 SDK 实现中：
EIP_DLR_processDLRFrame()返回而不处理 IFsignOnRcvdFlag == FALSE
我们注意到：
- 即使接受单播 Sign_On 帧后
signOnRcvdFlag、仍然为 false - 作为一种变通方法、我们暂时删除此检查以通过测试
问题：
设置 signOnRcvdFlag 为 true 的正确条件和时间是什么？
- 如果在接收到以下数据时设置该位：
- 多播 Sign_On？
- 单播 Sign_On（连续）？
- 两者都有？
存在许多风险
- SDK：适用于 AM243x 的工业通信 SDK 11.00.00.08
摘要
我们主要关注的是：
- 正确处理 单播连续 Sign_On 帧
- 符合 CIP Sign_On 上溢行为
- 目标实现保持一致
非常感谢有关正确设计或参考实现的任何指导。
