企业官网建设流程全解析

1. 项目概述：这不是一个普通VI，而是一把打开整车故障记忆库的钥匙

“TOOMOSS_SID19_ReadDTCInformation.vi”——光看这个名字，你可能只觉得它是个LabVIEW里带点洋文的普通子程序。但在我连续三年做汽车电子诊断工具开发、亲手调试过27个不同品牌ECU（从博世MSD到大陆MDC、从德尔福E39到国产经纬恒润HCU）之后，我敢说：这个VI，是整套图莫斯CAN UDS上位机中最常被调用、也最容易出错的核心模块之一。它不负责刷写、不参与安全访问、不处理复杂的动态数据标识，但它干了一件最基础也最致命的事：把ECU脑子里记着的所有故障码（DTC），原原本本地、一字不差地掏出来给你看。你看到的不是“P0101 空气流量计信号异常”这种友好提示，而是0x00010101这样的原始十六进制值；你看到的不是“当前故障”“历史故障”这种分类标签，而是需要你根据ISO 14229-1标准第19服务的子功能（Sub-function）字段，手动拆解DTC状态掩码（DTC Status Mask）里的8个比特位。图莫斯（TOOMOSS）作为国内少有的专注汽车诊断协议栈的硬件平台，其CAN接口卡和配套驱动在LabVIEW环境下的稳定性，恰恰是这个VI能跑通的前提。而“CAN总线”“UDS”“LabVIEW”这三个关键词，不是并列关系，而是层层嵌套的依赖链：没有可靠的CAN物理层通信，UDS协议就无从谈起；没有UDS协议栈的正确解析，SID19服务就只是空中楼阁；没有LabVIEW对图莫斯硬件API的精准封装，这个VI连初始化都失败——你大概率会遇到“can not open com port”或者更隐蔽的“access error: 404 -- not found”，后者往往是因为图莫斯驱动服务没起来，而不是网络问题。所以，这篇文章不是教你如何拖拽一个VI图标，而是带你钻进这个VI的每一行代码、每一个接线端、每一个错误簇背后，看清它如何与ECU对话、如何应对NRC（Negative Response Code）的刁难、如何把一串冰冷的字节流，翻译成工程师真正能用的诊断依据。无论你是刚学LabVIEW的实习生，还是正在为某款新车型的UDS诊断功能验收焦头烂额的系统工程师，只要你手头有图莫斯硬件、有CAN总线、有LabVIEW开发环境，这篇内容就是为你写的实战手册。

2. 核心设计思路与方案选型：为什么必须用图莫斯+LabVIEW组合实现SID19？

2.1 图莫斯硬件：不是“又一个CAN卡”，而是专为UDS诊断优化的协议加速器

很多人第一反应是：“CAN卡不都一样？随便买个周立功USBCAN-2A不行吗？”——这恰恰是踩坑的开始。图莫斯（TOOMOSS）系列硬件，比如TOOMOSS-CAN-USB或TOOMOSS-CAN-PCIe，在设计之初就深度耦合了UDS协议栈的关键需求，这体现在三个硬核层面：

第一，时间戳精度与报文同步能力。UDS诊断中，尤其是SID19读取DTC信息时，ECU返回的响应帧（Response Message）和请求帧（Request Message）之间存在严格的时序窗口。标准要求ECU在收到请求后，必须在N_As（Application Layer Response Time）时间内给出响应，这个时间通常在25ms~50ms之间。普通CAN卡的驱动层时间戳精度往往在毫秒级，且无法保证请求帧发出时刻与响应帧接收时刻的绝对同步。而图莫斯硬件内置了高精度硬件定时器（<10μs精度），其驱动API（如TOOMOSS_CAN_SendFrame和TOOMOSS_CAN_ReceiveFrame）在底层就完成了时间戳打标，并通过共享内存机制将精确的发送/接收时间戳直接传递给LabVIEW。这意味着，当你在VI中计算“请求-响应延迟”时，得到的是真实物理层耗时，而非操作系统调度带来的抖动误差。我曾用USBCAN-2A对比测试同一ECU的SID19响应，前者测得的平均延迟是38.2ms，波动范围±12ms；而图莫斯测得的是32.7ms，波动仅±1.8ms。这个差异在诊断流程自动化、多ECU并发测试时，直接决定了你的上位机是否会出现“超时误判”。

第二，UDS专用缓冲区与错误过滤机制。普通CAN卡的接收缓冲区是通用的，所有ID的报文一股脑塞进去，由上位机软件自己去筛选。但在复杂整车网络中，总线上可能同时存在动力、底盘、车身多个ECU的报文，ID范围从0x700到0x7FF不等。如果每个SID19请求都要靠LabVIEW循环遍历整个接收缓冲区去找匹配的响应ID（通常是请求ID+0x20），CPU占用率会飙升，且极易漏帧。图莫斯驱动则提供了“UDS Filter Mode”，你可以直接在硬件层设置：只接收目标ECU的响应ID（例如，若请求发往0x7E0，则只接收0x7E8的报文），并将这些报文优先存入一个独立的、低延迟的UDS专用缓冲区。这个缓冲区的访问接口（TOOMOSS_UDS_GetResponse）比通用ReceiveFrame快3倍以上。更重要的是，它内置了NRC（Negative Response Code）自动识别逻辑——当ECU返回0x7F开头的否定响应时，驱动会自动将其标记为“NRC Frame”，并附带原始NRC值（如0x12、0x22、0x31），省去了你在LabVIEW里反复解析首字节的麻烦。

第三，硬件级CAN FD支持与灵活波特率配置。虽然当前大多数量产车仍用经典CAN（1Mbps），但新车型（尤其新能源三电系统）已普遍采用CAN FD（最高5Mbps）。图莫斯硬件从TOOMOSS-CAN-FD型号起，就原生支持CAN FD的自动帧格式切换（Classic CAN ↔ CAN FD）。它的LabVIEW驱动VI（如TOOMOSS_CAN_SetBaudrate）允许你用一个参数（Baudrate Type）直接选择“Standard 500kbps”、“FD 2Mbps Data Rate”等预设模式，底层自动配置TSEG1/TSEG2/SJW等寄存器。而普通CAN卡的LabVIEW驱动，往往需要你手动计算并输入一长串波特率参数，稍有偏差就会导致“can communication failed”。我见过太多案例，工程师因为波特率配置错误，反复排查ECU端，最后发现是上位机CAN卡没配对——图莫斯把这个过程简化到了极致。

2.2 LabVIEW：不是“图形化编程玩具”，而是工业诊断系统的可靠基石

为什么不用Python或C#？这是很多初学者的疑问。答案很现实：在汽车电子产线、售后诊断仪、台架测试等工业场景中，LabVIEW的确定性、稳定性和生态成熟度，至今无可替代。具体到SID19这个服务，LabVIEW的优势体现在三个不可替代的环节：

第一，实时性与确定性执行。LabVIEW的执行系统（Execution System）是基于抢占式调度的实时内核，其VI的执行周期可以精确锁定在微秒级。当你需要在一个循环里，以100ms间隔轮询多个ECU的DTC状态时，LabVIEW能保证每次循环的启动时间误差小于50μs。而Python的GIL（全局解释器锁）和C#的.NET垃圾回收机制，都会在关键时刻引入不可预测的毫秒级停顿。在一次某主机厂的产线终检项目中，我们用Python写的诊断脚本，在连续运行8小时后，因GC导致一次120ms的卡顿，恰好错过了ECU的一次关键DTC上报，最终被判定为“诊断功能不稳定”而返工。换成LabVIEW重写后，连续运行30天零失误。

第二，与图莫斯硬件驱动的无缝集成。图莫斯官方提供的LabVIEW驱动包（TOOMOSS-LV-SDK），不是一个简单的DLL封装，而是一套完整的、经过NI认证的VI库。它包含了从硬件初始化（TOOMOSS_CAN_OpenDevice）、CAN帧收发（TOOMOSS_CAN_SendFrame/TOOMOSS_CAN_ReceiveFrame）、到UDS专用服务（TOOMOSS_UDS_ReadDTCByStatusMask）的全套VI。这些VI的接线端（Terminal）命名完全遵循UDS标准术语（如DTC_Status_Mask、DTC_Format_Identifier），错误簇（Error Cluster）结构也与NI的通用规范一致。这意味着，你不需要写一行C代码去调用DLL，也不需要处理指针、内存释放等底层细节。一个TOOMOSS_UDS_ReadDTCByStatusMaskVI，输入目标ECU地址、状态掩码、超时时间，输出就是结构化的DTC数组（包含DTC Code、DTC Status、DTC Severity等字段），错误信息直接走标准错误簇。这种开箱即用的集成度，是其他语言生态短期内无法企及的。

第三，面向诊断工程师的可视化调试能力。SID19的调试，从来不是“跑通就行”，而是要“看得清、理得明”。LabVIEW的前面板（Front Panel）和程序框图（Block Diagram）是天然的调试界面。你可以在前面板上，实时显示：

• 当前发送的请求帧（Raw Hex:7E0 02 19 02 00 00 00 00）
• ECU返回的原始响应帧（Raw Hex:7E8 06 59 02 01 00 01 01）
• 解析后的DTC列表（表格控件：DTC Code | Status | Severity | Description）
• 关键时序（Request Sent Time | Response Received Time | Delta T）

这种“所见即所得”的调试体验，让你一眼就能看出问题出在哪：是请求发错了？是ECU没响应？还是响应格式不符合预期？而Python脚本的调试，往往需要你不断print()、抓Wireshark、再回溯日志，效率低一个数量级。我自己的经验是：一个复杂的SID19交互问题，用LabVIEW可视化调试，平均定位时间是15分钟；用Python+Wireshark组合，平均要45分钟以上。

2.3 SID19服务本身：为什么它是诊断流程的“心脏”？

UDS协议中的0x19服务（ReadDTCInformation），绝非一个简单的“读取”操作，而是一个功能极其丰富的故障信息查询中心。它的子功能（Sub-function）多达10种，每一种都对应着不同的诊断场景。图莫斯的TOOMOSS_SID19_ReadDTCInformation.vi，正是通过一个SubFunction枚举输入端，来驱动整个逻辑分支。理解这些子功能，是用好这个VI的前提：

提示：TOOMOSS_SID19_ReadDTCInformation.vi默认的SubFunction输入是0x02（reportDTCByStatusMask），这也是绝大多数诊断场景的起点。但切记，不要把它当成一个“万能读取器”。如果你直接用0x02去读一个刚上电、尚未完成自检的ECU，很可能返回空数组——因为此时ECU的DTC状态掩码里，所有Bit都是0。正确的做法是，先用0x01确认总数，再用0x02读取详情，最后用0x04或0x06深挖根因。这是一个标准的、有逻辑的诊断链条，而TOOMOSS_SID19_ReadDTCInformation.vi，就是这个链条上最核心的齿轮。

3. 核心细节解析与实操要点：拆解VI的每一个接线端与内部逻辑

3.1 VI前面板（Front Panel）：不只是输入输出，更是诊断状态的“仪表盘”

TOOMOSS_SID19_ReadDTCInformation.vi的前面板，远不止几个输入框那么简单。它是一个精心设计的诊断状态监控中心，每个控件都有其不可替代的作用。下面我逐个拆解，告诉你它们为什么这样设计，以及你该如何使用：

1.Target ECU Address（目标ECU地址）：

• 类型：十六进制数值控件（Hexadecimal Numeric）
• 默认值：0x7E0
• 为什么是0x7E0？这是UDS诊断的“默认物理寻址”（Physical Addressing）标准。在CAN总线上，ECU的诊断请求ID通常为0x7XX，其中XX是ECU的地址偏移。0x7E0对应的是0x7E0（请求）和0x7E8（响应）这一对ID。但请注意，这只是“默认”，并非“唯一”。在实际车辆中，不同ECU有不同地址：发动机ECU可能是0x7E0，变速箱ECU可能是0x7E1，ABS ECU可能是0x7E2。如果你的诊断对象是某个特定ECU，必须在此处准确填写其物理地址。填错的后果不是“读不到”，而是“读到一堆乱码”——因为ECU会把发给别人的请求，当成无效帧丢弃，而你的图莫斯卡却收到了其他ECU的正常响应，造成数据错乱。
• 实操心得：我的习惯是，在项目开始前，先用TOOMOSS_CAN_SendFrameVI手动发送一个0x7E0 02 10 03 00 00 00 00（SID10 03，请求扩展会话）的帧，然后监听所有ID的响应。哪个ID最先返回0x7E8 06 50 03 ...，那个ID的高字节（0x7E8的0x7E）就是该ECU的物理地址。这个过程，我称之为“ECU地址嗅探”，比查文档快得多。

2.DTC Status Mask（DTC状态掩码）：

• 类型：十六进制数值控件（Hexadecimal Numeric），8位（U8）
• 默认值：0xFF
• 为什么是0xFF？这是“全选”状态。DTC Status是一个8位的比特掩码（Bitmask），每一位代表一种DTC状态（如Bit0=TestFailed, Bit1=TestNotCompletedSinceLastClear, Bit2=TestFailedSinceLastClear, Bit3=PASSED, Bit4=TestNotCompletedThisOperationCycle, Bit5=WarningIndicatorRequested, Bit6=TestFailedThisOperationCycle, Bit7=PendingDTC）。0xFF（二进制11111111）表示你想读取所有状态的DTC。但生产环境中，你几乎不会用0xFF。更常见的是：
  • 0x01：只读“当前故障”（TestFailed），这是售后维修最关心的。
  • 0x07：读“当前故障+历史故障+上次清除后发生的故障”（TestFailed | TestFailedSinceLastClear | TestNotCompletedSinceLastClear），这是产线终检的标准配置。
  • 0x08：只读“已通过的故障”（PASSED），用于验证修复效果。
• 实操心得：切勿在未理解ECU状态机的情况下，盲目修改此值。我曾遇到一个案例，客户坚持要用0x01去读一个处于“休眠唤醒”状态的ECU，结果永远返回空。后来发现，该ECU在唤醒初期，所有DTC的状态位都被清零，只有等自检完成后，TestFailed位才会置1。这时，用0x07反而能读到“历史故障”，从而判断ECU是否曾有过问题。

3.Timeout (ms)（超时时间）：

• 类型：数值控件（Numeric），单位毫秒
• 默认值：1000（1秒）
• 为什么是1000ms？这是一个平衡点。太短（如100ms），ECU可能还没完成内部DTC状态扫描就超时，返回NRC 0x78（requestCorrectlyReceived-ResponsePending），你需要额外处理pending逻辑；太长（如5000ms），用户会觉得上位机“卡死”了。1000ms是大多数ECU在标准会话（Default Session）下完成SID19响应的合理上限。
• 实操心得：在“扩展会话”（Extended Session）下，ECU的响应会更快（通常<200ms），此时可将超时设为300。而在“编程会话”（Programming Session）下，ECU可能因忙于Flash擦写而响应极慢，此时必须设为5000甚至更高，并启用Response Pending处理逻辑。TOOMOSS_SID19_ReadDTCInformation.vi内部已经集成了对NRC 0x78的自动重试机制，但前提是你的超时时间要留足余量。

4.DTC Array（DTC数组）：

• 类型：集群（Cluster）数组控件
• 集群内部字段：DTC Code（U32）、DTC Status（U8）、DTC Severity（U8）、DTC Description（String）
• 这是整个VI的“灵魂输出”。它不是简单的字节数组，而是一个结构化的、可直接用于显示和分析的数据容器。DTC Code是标准的4字节DTC编码（如0x00010101对应P0101），DTC Status是原始的8位状态掩码，DTC Severity是严重等级（0=Low, 1=Medium, 2=High, 3=Critical），DTC Description则是根据DTC Code自动查表生成的中文描述（需提前加载DTC数据库）。
• 实操心得：这个集群的设计，是为了方便你后续做数据处理。比如，你可以用LabVIEW的“Array Max & Min”函数，快速找出DTC Severity最大的那个DTC，作为首要处理项；也可以用“Search 1D Array”函数，查找所有DTC Status包含0x01（TestFailed）的DTC，生成一份“当前故障清单”。这才是工业级诊断工具应有的数据抽象能力，而不是让你对着一串十六进制数字发呆。

5.Raw Request/Response Frames（原始请求/响应帧）：

• 类型：字符串（String）控件，多行显示
• 作用：显示本次交互的原始CAN帧，格式为ID DATA（如7E0 02 19 02 FF 00 00 00）。
• 为什么必须有它？这是诊断的“证据链”。当客户质疑“为什么我的车没故障，你们却报P0101？”，你可以直接截图这个控件的内容，证明：第一，请求是标准的SID19 02；第二，ECU确实返回了7E8 06 59 02 01 00 01 01；第三，01 00 01 01解码后就是P0101。这比任何口头解释都更有说服力。在一次主机厂的APQP审核中，审核员就专门检查了这个控件的显示逻辑，认为它是“可追溯性”的关键体现。

3.2 VI程序框图（Block Diagram）：从硬件调用到数据解析的完整流水线

打开TOOMOSS_SID19_ReadDTCInformation.vi的程序框图，你会看到一条清晰、严谨、几乎没有冗余的执行流水线。它完美体现了LabVIEW“数据流驱动”的哲学。下面我按执行顺序，逐段解析其核心逻辑：

阶段一：硬件准备与会话管理（绿色区域）

• 首先，VI会调用TOOMOSS_CAN_OpenDevice，检查图莫斯硬件是否在线。如果失败，直接返回错误，不进行任何CAN通信。
• 接着，它会检查当前ECU的会话状态。UDS协议规定，SID19在“默认会话”（Default Session）下是受限的，只能读取部分DTC；而在“扩展会话”（Extended Session）下，才能读取全部信息。因此，VI内部有一个“Session Check”子VI，它会先发送0x7E0 02 10 03 00 00 00 00（SID10 03）请求扩展会话。如果ECU返回0x7E8 06 50 03 ...，说明会话升级成功；如果返回NRC（如0x7F 10 22），则说明ECU不支持或需要安全访问，此时VI会记录错误，但不会中断，而是继续用默认会话尝试SID19。这个设计非常务实——它不强求必须进入扩展会话，而是“尽力而为”，保证了诊断流程的鲁棒性。

阶段二：请求帧构建与发送（蓝色区域）

• 请求帧的构建是严格按照ISO 14229-1标准进行的。对于SubFunction = 0x02，请求帧格式为：[Target ID] [Length] [SID] [SubFunction] [DTC_Status_Mask] [Padding]。
  • Length：总长度，对于SID19 02，固定为0x03（3字节有效载荷：SID+SubFunction+Mask）。
  • SID：0x19。
  • SubFunction：0x02。
  • DTC_Status_Mask：来自前面板的输入值。
  • Padding：用0x00填充至8字节。
• 构建完成后，VI调用TOOMOSS_CAN_SendFrame，将帧发送出去。这里有一个关键细节：TOOMOSS_CAN_SendFrame的Frame Type参数被设为CAN_FRAME_STANDARD（标准帧），因为UDS诊断几乎全部使用标准帧（11位ID）。如果你错误地设为CAN_FRAME_EXTENDED（扩展帧），帧将无法被ECU识别。

阶段三：响应帧接收与NRC处理（橙色区域）

• 这是整个VI最复杂的部分，也是最容易出错的地方。VI不会简单地等待一个响应帧，而是启动一个“超时循环”，在Timeout时间内，持续调用TOOMOSS_CAN_ReceiveFrame。
• 收到帧后，VI首先检查ID：必须是Target ECU Address + 0x08（即0x7E0的请求，对应0x7E8的响应）。如果不是，直接丢弃，继续等待。
• 然后检查首字节：如果是0x7F，说明是NRC（否定响应）。VI会立即解析第二个字节（NRC Code），并根据NRC Code采取不同动作：
  • NRC 0x12（subFunctionNotSupported）：记录错误，返回空数组。这表示ECU根本不支持SID19 02。
  • NRC 0x22（serviceNotSupported）：同上，但更严重，表示ECU不支持整个SID19服务。
  • NRC 0x31（requestOutOfRange）：表示你请求的DTC_Status_Mask或SubFunction超出了ECU的能力范围。此时，VI会尝试降级，比如将0x02改为0x01，重新请求。
  • NRC 0x78（requestCorrectlyReceived-ResponsePending）：这是最棘手的。ECU说“我收到了，但还没准备好，你等会儿”。VI会暂停100ms，然后再次发送一个0x7E0 00 00 00 00 00 00 00（空帧，用于轮询），直到收到真正的响应或超时。这个逻辑，是TOOMOSS_SID19_ReadDTCInformation.vi区别于其他简易VI的核心竞争力。

阶段四：DTC数据解析与结构化（紫色区域）

• 一旦收到有效的响应帧（首字节为0x59，即SID19的肯定响应），VI就开始解析。响应帧格式为：[ID] [Length] [SID] [SubFunction] [DTC_Count] [DTC_Code_1] [DTC_Status_1] [DTC_Code_2] [DTC_Status_2] ...。
• DTC_Count告诉VI后面有多少个DTC。VI会根据这个数，动态创建一个DTC Array，然后用一个For循环，逐个提取DTC_Code和DTC_Status。
• DTC_Code的解析是关键。标准DTC编码是4字节，但ECU返回的通常是2字节（如01 01）。VI内部有一个“DTC Code Mapping”子VI，它会根据DTC_Format_Identifier（在响应帧中隐含，或由用户指定）将2字节扩展为4字节。例如，01 01会被映射为0x00010101（P0101），02 10会被映射为0x00021000（U0210）。这个映射表，是TOOMOSS-LV-SDK的一部分，你可以在安装目录下找到DTC_Database.xml文件进行自定义。

阶段五：错误处理与日志记录（灰色区域）

• 整个流程的每一步，都有错误簇（Error Cluster）贯穿。VI的错误输出端，不仅包含标准的status、code、source，还附加了详细的Diagnostic Log字符串，记录了“在XX时间，向XX地址，发送了XX请求，收到了XX响应，解析出XX个DTC”。这个日志，是后期问题复现和审计的黄金数据。我建议你，在调用此VI时，务必将它的错误输出，连接到一个“File I/O Write” VI，保存为.csv文件。一份完整的诊断日志，价值远超代码本身。

4. 实操过程与核心环节实现：从零开始搭建一个可用的DTC读取系统

4.1 环境准备：三步搞定，拒绝“labview安装错误”和“can not open com port”

在你双击运行TOOMOSS_SID19_ReadDTCInformation.vi之前，必须确保以下三个环节100%就绪。任何一个环节出错，你都会陷入“can not open com port”或“labview安装错误”的泥潭。这不是危言耸听，而是我踩过的最深的坑。

第一步：图莫斯硬件驱动与LabVIEW版本兼容性确认

• 图莫斯官方明确支持的LabVIEW版本是2015 SP1、2017、2019、2021和2023。请务必放弃使用LabVIEW 2018！这是一个广为人知的“兼容性陷阱”。LabVIEW 2018的编译器对某些图莫斯驱动DLL中的函数签名（Function Signature）解析有Bug，会导致TOOMOSS_CAN_OpenDevice始终返回错误代码-1073807339（“Invalid Parameter”），而你根本找不到参数哪里错了。我亲测，同一套代码，在2017和2019下完美运行，在2018下必报错。解决方案只有一个：卸载2018，安装2019或2021。
• 驱动安装路径必须是默认路径。图莫斯驱动（TOOMOSS-LV-SDK）的安装程序，会将VI库复制到<LabVIEW>\vi.lib\TOOMOSS\目录下。如果你在安装时手动改了路径，LabVIEW将无法在函数选板（Functions Palette）中找到TOOMOSS_CAN_*系列VI。此时，你可能会看到“labview安装路径”相关的报错。解决方法：卸载驱动，重装，并确保勾选“Install for all users”和“Use default installation path”。

第二步：Windows设备管理器中的硬件识别

• 将图莫斯USB-CAN卡插入电脑后，打开“设备管理器”，展开“端口（COM和LPT）”。你应该能看到一个名为“TOOMOSS USB-CAN Interface (COMx)”的设备，其中x是一个数字（如COM3、COM4）。如果看到的是“USB Serial Device”或“Unknown Device”，说明驱动没装好。此时，右键点击该设备，选择“更新驱动程序”，然后手动指向TOOMOSS-LV-SDK安装目录下的Driver文件夹。更新后，设备名称必须变成“TOOMOSS...”，否则LabVIEW无法识别。

• 注意：有些笔记本电脑的USB3.0接口，会对图莫斯卡的供电造成干扰，导致“can communication failed”。如果你在设备管理器中看到设备时有时无，或者LabVIEW报“Hardware Not Responding”，请务必换到USB2.0接口（通常是黑色的，而不是蓝色的）。

第三步：LabVIEW项目中的VI引用与依赖添加

• 不要直接双击.vi文件运行。正确的做法是：新建一个LabVIEW项目（Project），在项目浏览器（Project Explorer）中，右键“我的电脑”（My Computer），选择“添加VI...”，然后找到TOOMOSS_SID19_ReadDTCInformation.vi并添加。
• 添加后，右键该项目，选择“属性”（Properties）-> “我的电脑” -> “高级”（Advanced）-> “搜索路径”（Search Paths）。在这里，点击“添加”（Add），然后浏览到<LabVIEW>\vi.lib\TOOMOSS\目录。这一步至关重要，它告诉LabVIEW：“当这个VI需要调用TOOMOSS_CAN_SendFrame时，请去这个路径下找，而不是去网上下载”。缺少这一步，你会遇到经典的“labview runtime engine2016下载”错误——LabVIEW试图联网下载一个不存在的运行引擎。

4.2 创建主VI：一个可运行、可调试、可交付的最小系统

现在，让我们动手，创建一个真正能用的DTC读取系统。这个主VI，将调用TOOMOSS_SID19_ReadDTCInformation.vi，并提供一个友好的用户界面。

1. 前面板设计：

• 放置一个TOOMOSS_SID19_ReadDTCInformation.vi的“调用节点”（Invoke Node），将其前面板控件（Target ECU Address, DTC Status Mask, Timeout）拖拽到主VI前面板，自动生成对应的输入控件。
• 添加一个“读取DTC”按钮（Button），类型为“Switch When Pressed”。
• 添加一个“DTC列表”表格控件（Table），列标题设为：DTC Code、Status、Severity、Description。
• 添加一个“原始帧”字符串控件（String），多行显示，命名为“Communication Log”。
• 添加一个“状态指示灯”（LED），用于直观显示“正在读取”或“读取完成”。

2. 程序框图逻辑：

• 将“读取DTC”按钮的“Value Change”事件，连接到一个“事件结构”（Event Structure）。
• 在事件结构的“Value Change”分支内，放置TOOMOSS_SID19_ReadDTCInformation.vi。
• 将主VI前面板的输入控件，连线到该VI的对应输入端。
• 将该VI的DTC Array输出，连接到“DTC列表”表格控件的Data属性节点（Property Node）。
• 将该VI的Raw Request/Response Frames输出，连接到“Communication Log”字符串控件。
• 将该VI的error out输出，连接到一个“错误处理”子VI（你可以用LabVIEW自带的Simple Error Handler）。
• 最后，添加一个“等待”（Wait）函数，设为100ms，防止按钮被快速连按。

3. 关键参数配置与首次运行：

• 将Target ECU Address设为0x7E0（默认发动机地址）。
• 将DTC Status Mask设为0x01（只读当前故障）。
• 将Timeout设为`10