上下文： 我正在尝试使用 python-can 通过带有 MessageSync 迭代器对象实现的向量接口重播 BLF 文件，并且 can.send 对产生的消息进行操作。虽然它按预期运行 20-30 秒，但之后它在发送 CAN 消息时不断引发 ERR_QUEUE_FULL 异常。已尝试使用 can_bus.flush_tx_buffer() 和 can_bus.reset() 处理该问题，但没有效果。我知道传输缓冲区已满，而消息在给定段写入太快导致缓冲区溢出。用法：
replayReaderObj = LogReader(replay_file_path)
msgSyncObj = MessageSync(messages=replayReaderObj, timestamps=True)
我正在使用 for 循环通过 msgSyncObj 进行迭代，并对消息使用 can.send() （假设消息不是错误帧）。考虑默认参数 gap(0.0001) 和 skip(60)，在这种情况下，与重播文件相比，重播时间戳显着延迟。因此，在下一次尝试中包括作为 0 的间隙，以确保仅考虑偏移差异。它对齐重播时间戳，但会在几秒钟内导致缓冲区溢出。
在 Vector CANoe 重放块上运行时，相同的重放文件运行良好，在给定的重放持续时间（+10%）内没有任何缓冲区问题。
问题： 谁能阐明python-can和Vector CANoe（都在Win10 PC上运行）是否有不同的配置传输队列缓冲区的方式？任何关于如何增加 python-can 使用的传输队列缓冲区的建议以及处理此类缓冲区溢出（因为 flush_tx_buffer 没有任何影响）都受到高度赞赏。注意：在 Vector Hardware Configuration 中，传输队列大小配置为 256 条消息。在我想更改它之前，我不确定 python-can 是否使用相同的配置。
附加上下文 操作系统和版本：Win 10 Python 版本：Python 3 python-can 版本：3.3.4 python-can interface/s（如果适用）：Vector VN1630
还有另一个用于确认 Tx 消息的真实 ECU。如果我在连续消息之间保持适当的等待时间（10 毫秒 - Python Windows 中的 time.sleep() 可以提供的最小值），这运行良好。缺点是使用等待时间注入，它需要实际重放时间的 6-7 倍。
让我知道在此之上的任何进一步信息。抱歉，我将无法共享跟踪文件，因为它是专有的，但有关其性质的任何详细信息我都可以回复。