• 🍅 我是蚂蚁小兵，专注于车载诊断领域，尤其擅长于对CANoe工具的使用
• 🍅 寻找组织 ，答疑解惑，摸鱼聊天，博客源码，点击加入👉【相亲相爱一家人】
• 🍅 玩转CANoe，博客目录大全，点击跳转👉

---

• 如下图，在使用CANoe配置LIN总线的诊断时，需要选择Scheduling Setting 选项，那么这4个选项有什么不同呢？
  

Scheduling Settings

• LIN诊断使用两个预定义的LIN帧，主请求和从响应。因此，当前活动的时间表必须包含它们。

• LIN 2.1规范假设存在一个包含这些帧的单独表，即主请求帧（0x3C）和从响应帧(0x3D)各一个表。因此，系统必须在诊断请求和诊断响应之间在这两个表之间切换。

• 如下面的LDF文件，MasterReq_Table 和SlaveResp_Table 是各自一张表，在总线中没有诊断的情况下，只运行Send 调度表（定义的都是APP报文）

Selected Scheduling

• 使用当前运行的进度表。确保该表同时包含主请求帧和从响应帧是很重要的，一般情况下，APP报文的调度表并不会包含诊断报文的，所以一般不选该选项，否则诊断请求无法发出。

Diagnostics only

• 搜索LDF文件以确定是否存在主请求帧和从响应帧的单独进度表。如果是这种情况，系统将在诊断请求和诊断响应之后自动在这两个表之间切换，否则禁用此选项。诊断通信完成后，将再次运行在启动诊断请求之前运行的进度表。
• 如下面示例，没有诊断的时候，总线一直运行Send调度表（APP报文），发送诊断请求时，自动切换到MasterReq-Table调度表，发送完成后，自动切换到SlaveResp_Table调度表，然后发送0x3D报头，从节点数据响应完毕后，系统又将调度表切换到Send调度表。

Interleaved

• 与仅诊断模式一样，主请求和从响应帧的单独进度表必须存在。如果传输诊断请求，则在请求的每个段之间运行一次在请求启动之前运行的进度表。同样的行为也适用于诊断响应。诊断通信完成后，将再次运行在开始诊断通信之前运行的进度表

• 对比下Diagnostics only模式，Interleaved模式在诊断请求发出后会再次切回到APP报文调度表，然后在切回到诊断响应调度表，最后响应完毕后再次切回到APP报文调度表。

Direct sending

• 当直接传输时，主请求报头是自动生成的，独立于调度。如果存在Master Request表和Slave Response表，系统会自动切换到Slave Response表进行诊断响应。如果不是这种情况，则必须在配置中建立一个包含Slave响应帧的表，确保在这种模式下指定的表不包含主请求帧是很重要的，因为这将导致主请求报头传输过于频繁。

• 测试结果如下， 该模式下，发送诊断请求时，没有切换调度表直接发送，然后切换到诊断响应调度表，之后一直停留在该调度表，没有切回APP报文调度表

---

• 🚩要有最朴素的生活，最遥远的梦想，即使明天天寒地冻，路遥马亡！
  
  
• 🚩如果这篇博客对你有帮助，请 “点赞” “评论”“收藏”一键三连 哦！码字不易，大家的支持就是我坚持下去的动力。