gpt4 book ai didi

can-bus - 使用 ELM327 接收 CAN 报文时的流量控制报文

转载 作者:行者123 更新时间:2023-12-05 04:16:06 26 4
gpt4 key购买 nike

我正在尝试制作一个在 Windows 下运行并与 ELM327 设备通信的软件。我创建了第一个版本,然后我进入了我的 SMART ForTwo (SMART 451) 车辆,我设法连接了仪表盘(发送 CAN ID 为 782,接收 CAN ID 为 783)。但是我对流量控制有很大的问题。这是日志:

TX:ATI接收端:ELM327 v1.5a

TX:ATE0接收:ATE0 正常

TX:ATSP6接收:好的

TX:ATH1接收:好的

TX:ATL1接收:好的

TX:ATCFC1接收:好的

TX:ATFCSM0接收:好的

TX:阿塔尔接收:好的

TX:ATSH782接收:好的

TX:ATCRA783接收:?

TX:ATST64接收:好的

TX:1092接收:783 02 1A 87

TX: 1A87接收:783 10 16 5A 87 05 6E 00 08

我使用了另一个工具,我看到 ELM327 设备立即发送流量控制帧。是这样的:

891.438 782 02 1A 87

891.444 783 10 16 5A 87 05 6E 00 08

891.444 782 30 00 00 00 00 00 00 00

如您所见 - 流量控制帧与从其他设备发送的第一帧同时发送。我确定其他设备在接收“流量控制”帧时遇到问题。我研究了 ELM327 文档,但没有找到有关如何延迟流控制帧的任何信息。我应该如何正确发送请求“1A 87”并收到响应?

最佳答案

这是一个旧帖子,但可能对其他人有帮助!

这是我在与 SPI 连接的 MCP2515 上使用第一帧 (FF) 和流量控制 (FC) 的经验。

首先,您应该始终在 FF 消息之后发送 FC 消息,而不是同时发送。

其次,诊断读取器可以使用 ECU 响应帧中的 ID 继续与特定 ECU 通信。特别是,多帧通信需要响应特定的 ECU ID 而不是 ID 7DF。用通俗易懂的语言,您不应该发送 ID 为 7DF 的 FF 消息,您应该对您希望接收连续帧的确切 ECU 进行寻址。例如请求汽车 VIN(基于 Golf VII 的真实信息):

7DF 02 09 00 00 00 00 00 00//发送请求

7E8 10 14 49 02 01 57 56 57//从主ECU接收

7E0 30 00 00 00 00 00 00 00//寻址主 ECU 而不是 7DF !!

7E8 21 5A 5A 5A 41 55 5A 45//连续消息由7E0发送!

7E8 22 50 35 33 30 36 38 35

希望对您有所帮助!

关于can-bus - 使用 ELM327 接收 CAN 报文时的流量控制报文,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/29213988/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com