你遇到的XL_ERR_QUEUE_IS_FULL（发送队列溢出）问题在无过滤的CAN桥接场景里非常典型，结合你的CAPL代码和已做的配置调整，我整理了几个针对性的解决方向：

1. 修复CAPL代码的循环转发问题 #

你的当前代码最大的隐患是无限制的报文循环转发：通道1收到的报文被转发到通道3后，通道3又会把这个转发过来的报文再发回通道1，短时间内会生成海量重复报文，直接撑爆发送队列。

修改代码，通过判断报文来源打破循环：

variables{
  message can1.* msgCAN1;
  message can3.* msgCAN3;
}

on message can1.* {
  // 只转发从外部ECU接收的报文，忽略CANoe自身发送的报文
  if(!this.isLocal()) {
    msgCAN3 = this;
    output(msgCAN3);
  }
}

on message can3.* {
  if(!this.isLocal()) {
    msgCAN1 = this;
    output(msgCAN1);
  }
}

或者通过报文方向判断实现相同效果：

on message can1.* {
  if(this.dir == rx) { // 仅处理接收自外部的报文
    msgCAN3 = this;
    msgCAN3.dir = tx; // 标记为发送方向，避免回环
    output(msgCAN3);
  }
}

on message can3.* {
  if(this.dir == rx) {
    msgCAN1 = this;
    msgCAN1.dir = tx;
    output(msgCAN1);
  }
}

2. 增加报文过滤，减少转发总量 #

如果你的测试只针对特定ID的报文进行篡改，没必要转发总线上的所有报文：

• 在CAPL中添加ID过滤，只转发目标报文：

on message can1.* {
  if(!this.isLocal() && (this.id == 0x123 || this.id == 0x456)) {
    msgCAN3 = this;
    output(msgCAN3);
  }
}

• 也可以在CANoe硬件通道的接收设置里开启ID过滤规则，从根源减少进入CAPL处理流程的报文数量。

3. 优化CANoe的发送调度配置 #

• 打开Options > Preferences > CAN，在Transmit选项卡将发送调度模式改为Event-driven，让CANoe更及时地处理发送队列（默认Polling模式的处理效率较低）。
• 降低CAPL脚本的执行优先级：在CAPL编辑器的Properties面板中，将脚本优先级设为Low，避免CAPL占用过多CPU资源导致发送队列无法及时排空。

4. 硬件与驱动层面的调整 #

• 尝试更新VN1640A的最新驱动程序，旧版本驱动可能存在发送队列处理的兼容性bug。
• 查看CANoe的硬件负载统计：在Measurement > Diagnostic > Hardware中观察通道的报文负载率，如果负载接近100%，说明当前硬件无法承受总线流量，可尝试降低CAN总线波特率（测试允许的前提下），或者更换更高性能的CAN接口设备。

5. 按需启用报文节流（极端场景） #

如果必须全量转发且硬件负载拉满，可以在CAPL中添加简单的节流逻辑，限制每秒转发的报文数量（注意：这种方式会丢失部分报文，仅适合对实时性要求不高的场景）：

variables{
  dword lastSendTime = 0;
  int sendInterval = 1; // 每1ms转发一个报文，可根据实际情况调整
}

on message can1.* {
  if(!this.isLocal() && (timeNow() - lastSendTime >= sendInterval)) {
    msgCAN3 = this;
    output(msgCAN3);
    lastSendTime = timeNow();
  }
}

内容的提问来源于stack exchange，提问作者aagargoura