3、诊断控制台实战：Diagnostic Console基本操作、发送诊断请求、查看诊断响应

好，咱们直接进入正题。诊断控制台（Diagnostic Console）是CANalyzer里我最常用的工具之一。说实话，刚入行那会儿，我对着这个界面愣了半天——按钮太多，不知道从哪下手。但摸透了之后，你会发现它其实很顺手。

3.1 打开诊断控制台

有两种方式可以打开它。我个人习惯用第一种，因为快。

• 方法一：在CANalyzer菜单栏点击 Tools → Diagnostics → Diagnostic Console。
• 方法二：直接按快捷键 Ctrl+Shift+D（嗯，这个快捷键我记了很久才记住）。

打开后你会看到一个分栏的窗口。左边是请求区，右边是响应区。中间有个大大的“Send”按钮。别急着点，先配置一下。

3.2 配置诊断通道

在发送任何请求之前，你得告诉CANalyzer：你要跟谁说话？用什么协议？

点击Console窗口里的 Configuration 按钮（像个齿轮图标）。你会看到：

• Channel：选择物理通道，比如CAN 1或CAN FD 2。
• Protocol：选UDS（ISO 14229）或者OBD（ISO 15031）。大部分项目用UDS。
• Target Address：ECU的逻辑地址。比如发动机ECU通常是0x7E0，网关是0x7E2。
• Source Address：诊断工具的地址，一般是0x7DF或0x7E8。

我记得有一次，我在配置地址时把Source和Target填反了。结果ECU一直不回响应，我排查了半小时才发现。你想想看，地址都错了，车机怎么可能理你？

3.3 发送诊断请求

配置好了，咱们来发个请求试试。以读取ECU的软件版本号为例（诊断ID：0x22，DID：0xF190）。

在Console的请求区，你会看到几个输入框：

• Service：输入 22（ReadDataByIdentifier）。
• SubFunction：一般留空，除非服务需要子功能。
• Data：输入 F1 90（DID的高字节和低字节）。

然后点击 Send。就这么简单。

如果你喜欢手动拼报文，也可以用 Raw 模式。在Raw模式下，你需要自己构造完整的CAN帧数据。比如：

02 22 F1 90 00 00 00 00

解释一下：02 是数据长度（2字节），22 是服务ID，F1 90 是DID。后面的 00 是填充位，CAN帧必须填满8字节。

我个人更推荐用结构化输入（Service/SubFunction/Data模式），因为不容易出错。Raw模式适合老手，或者当你需要测试一些非标准请求时。

3.4 查看诊断响应

发送请求后，响应会出现在右边的 Response 区域。正常情况下，你会看到：

62 F1 90 01 02 03 04

解读一下：62 是肯定响应（服务ID + 0x40），F1 90 是DID，后面的 01 02 03 04 就是软件版本号数据。

如果ECU返回了否定响应，比如：

7F 22 12

这表示 22 服务被拒绝，错误码是 12（子功能不支持）。这时候你就得查UDS标准文档，看看0x12到底是什么意思。

3.5 常用诊断服务速查表

为了方便你快速上手，我整理了几个最常用的诊断服务。建议你收藏一下：

嗯，这张表我建议你打印出来贴在工位上。我刚开始做诊断测试时，就是靠这张表活下来的。

3.6 避坑指南：常见问题与解决

最后，分享几个我亲身踩过的坑：

• ECU没响应？ 先检查总线物理层——CAN_H和CAN_L电压对不对？终端电阻有没有接？我曾经被一根虚焊的CAN线折磨了一整天。
• 响应总是否定？ 看看是不是会话模式不对。比如你在默认会话（0x01）下尝试写入操作，ECU肯定会拒绝。先发0x10 03切换到扩展会话再说。
• 数据长度不对？ UDS对数据长度有严格要求。比如0x22服务，DID必须是2字节，多一个少一个都不行。我见过有人把DID写成3字节，ECU直接不理你。
• 时序问题： 诊断请求之间要有间隔。连续狂发请求，ECU会认为你是在攻击它。一般建议间隔至少20ms。

好了，诊断控制台的基本操作就这些。说白了，就是配置地址、发请求、看响应。但细节决定成败，地址配错、会话不对、时序乱来，都会让你抓狂。多练几次，你也能像我一样闭着眼睛操作。