4、CAPL事件处理：系统事件、CAN事件、定时器事件
CAPL脚本的核心，说白了就是「事件驱动」。你写一个函数，它不会自己跑，得靠某个事件去触发它。就像你家里的门铃，没人按它就不响。CAPL里的事件，就是那个「按门铃的人」。
我个人习惯把CAPL事件分成三大类：系统事件、CAN事件、定时器事件。这三类几乎覆盖了日常开发中90%的场景。今天咱们就一个一个捋清楚。
4.1 系统事件：on start 与 on preStart
系统事件是CAPL脚本的「生命起点」。你想想看，脚本加载后总得有个地方开始执行吧？on start 和 on preStart 就是干这个的。
4.1.1 on preStart
on preStart 在仿真启动的最早期被调用。有多早？早到CANoe的通信栈还没完全初始化。这时候你干不了什么复杂的事，但可以做些「准备工作」。
典型用途：初始化全局变量、加载配置文件、设置仿真参数。
on preStart
{
// 我习惯在这里把全局变量清零
gCounter = 0;
gErrorFlag = 0;
// 加载一个DBC文件路径到字符串
gDbcPath = "C:\\Project\\CAN\\vehicle.dbc";
write("preStart: 准备工作完成");
}嗯，这里要注意：on preStart 里不能调用 output() 发送报文，因为CAN控制器还没准备好。我曾经犯过这个错，调试了半天才发现报文根本没发出去。
4.1.2 on start
on start 是真正的「启动事件」。这时候CANoe已经完全就绪，你可以放心地初始化定时器、发送第一帧报文、或者建立TCP连接。
on start
{
// 启动一个100ms的循环定时器
setTimer(tCycle, 100);
// 发送一条初始化报文
message 0x100 msgInit = {dlc = 8, byte(0) = 0xAA, byte(1) = 0x55};
output(msgInit);
write("系统启动完成，定时器已开启");
}我在项目中遇到过一个问题：某ECU需要在启动后200ms内收到第一帧报文，否则会进入故障模式。我就在 on start 里立刻发送，完美解决。
小技巧：如果你需要在多个脚本间同步启动动作，可以在 on start 里设置一个全局事件标志，其他脚本轮询这个标志。
4.2 CAN事件：on message
on message 是CAPL里最常用的事件，没有之一。只要总线上有报文过来，它就会被触发。你想想看，做CANoe仿真，不就是跟报文打交道吗？
4.2.1 基本用法
on message 0x123
{
// 只处理ID为0x123的报文
write("收到报文 0x123, 数据: %02x %02x", this.byte(0), this.byte(1));
}
on message *
{
// 处理所有报文（慎用，性能开销大）
// 我一般只在调试时用这个
}这里有个关键点：this 关键字。在 on message 事件里，this 代表当前收到的报文对象。你可以通过 this.byte(index) 访问数据字节，通过 this.id 获取报文ID。
4.2.2 带DBC的用法
如果你加载了DBC文件，那就更爽了。可以直接用信号名访问。
on message EngineData
{
// EngineData 是DBC里定义的一个报文
int speed = this.Speed; // Speed是DBC里的信号
int rpm = this.RPM;
if (rpm > 6000)
{
write("警告：发动机转速过高！");
}
}我个人习惯：只要项目有DBC，我一定用信号名访问。为什么？可读性强，而且DBC里信号起始位、长度都定义好了，不容易出错。
避坑指南：我曾经在 on message * 里写了一个复杂的解析逻辑，结果总线负载一高，脚本直接卡死。后来改成只监听需要的ID，性能立马好了。记住：能用具体ID就别用通配符。
4.3 定时器事件：on timer
定时器事件是CAPL里实现「周期性动作」和「延时动作」的法宝。没有它，你连个周期发送报文都做不了。
4.3.1 定时器的类型
| 类型 | 函数 | 说明 |
|---|---|---|
| 一次性定时器 | setTimer(t, delay) | 延迟delay ms后触发一次 |
| 循环定时器 | setTimerCyclic(t, period) | 每隔period ms触发一次 |
| 停止定时器 | cancelTimer(t) | 取消一个正在运行的定时器 |
4.3.2 代码示例
// 声明定时器变量
timer tDelay; // 一次性
timer tCycle; // 循环
on start
{
// 启动一个2秒的一次性定时器
setTimer(tDelay, 2000);
// 启动一个100ms的循环定时器
setTimerCyclic(tCycle, 100);
}
on timer tDelay
{
write("2秒到了，执行一次性动作");
// 比如：发送一条唤醒报文
message 0x100 msgWake = {dlc = 8, byte(0) = 0x01};
output(msgWake);
}
on timer tCycle
{
// 每100ms执行一次
gCounter++;
write("循环定时器第 %d 次触发", gCounter);
// 如果计数器到100，停止定时器
if (gCounter >= 100)
{
cancelTimer(tCycle);
write("循环定时器已停止");
}
}嗯，这里有个细节：定时器的精度是毫秒级，但实际触发时间会有微小抖动。如果你需要微秒级的精确控制，得用硬件定时器，CAPL的 timer 做不到。
4.3.3 定时器的坑
我曾经踩过的坑：在 on message 里调用 setTimer，结果报文来得太快，定时器还没触发又被重置了。后来我加了一个标志位判断，只有定时器空闲时才重新设置。
on message 0x200
{
if (!gTimerActive)
{
setTimer(tDelay, 500);
gTimerActive = 1;
}
}
on timer tDelay
{
write("延时动作执行");
gTimerActive = 0; // 重置标志
}4.4 三种事件的配合使用
实际项目中，这三种事件很少单独使用。我举个例子你就明白了：
// 场景：模拟一个ECU的上电行为
on preStart
{
gPowerState = 0; // 0: 未上电
}
on start
{
// 上电后延迟100ms发送第一帧
setTimer(tPowerUp, 100);
}
on timer tPowerUp
{
gPowerState = 1;
message 0x100 msgPower = {dlc = 8, byte(0) = 0x01};
output(msgPower);
write("ECU上电完成");
// 启动心跳报文，每50ms发一次
setTimerCyclic(tHeartbeat, 50);
}
on timer tHeartbeat
{
message 0x101 msgHB = {dlc = 8, byte(0) = gCounter++};
output(msgHB);
}
on message 0x500
{
// 收到休眠指令，停止心跳
if (this.byte(0) == 0x00)
{
cancelTimer(tHeartbeat);
gPowerState = 0;
write("ECU进入休眠");
}
}你看，on preStart 初始化状态，on start 启动延时，on timer 做周期性动作，on message 响应外部指令。四种事件配合得天衣无缝。
总结一下：
- on preStart：做最早期准备，不能发报文
- on start：正式启动，可以发报文、启定时器
- on message：处理接收到的CAN报文，尽量用具体ID
- on timer：实现延时和周期动作，注意不要频繁重置
说白了，CAPL事件处理就是「什么时候干什么事」。你把每个事件的触发时机搞清楚了，写脚本就跟搭积木一样简单。下次遇到一个需求，先想想：这个动作该放在哪个事件里？想明白了，代码自然就写出来了。