XL_ERR_QUEUE_IS_FULL when sending large data (Vector hardware)

[dpatel20]

Describe the bug

I am using udsoncan to run some diagnostics, including 'Transfer Data'. As part of this, I send 4kB packets using transfer data of UDS (utilising python-can-isotp via udsoncan).

Randomly I get XL_ERR_QUEUE_IS_FULL whilst python-can is part way through.

What I believe is happening is that xlCanTransmit() is being called before it has finished sending the previous message. I've checked the python CAN isotp code and cannot see anywhere that it might be sending a second call to transmit before the previous one has finished.

Only seems to be a problem on a multi-frame message.

Whilst I was debugging, I put a print message after the xlCanTransmit() and the problem did not occur. I know that the print will cause a delay and, I presume, that delay is enough to stop the issue. In fact, I can even do something similar in the python-can-isotp send and it has the same effect - i.e. putting a print (delay) anywhere in the send chain seems to be sufficient.

Does xlCanTransmit() not block until the current frame is transmitted? I presume the same issue could occur if two threads were trying to send on the same connection??

Perhaps I am missing a parameter to set?

# This the setup. Adding in isotp_params doesn't stop the issue.
bus = VectorBus(channel=0, bitrate=500000)
tp_addr = isotp.Address(isotp.AddressingMode.Normal_11bits, txid=0x7B5, rxid=0x7BD)
stack = isotp.CanStack(bus=bus, address=tp_addr)
conn = PythonIsoTpConnection(stack) 
client = Client(conn, config=config)

Additional context

OS and version: Windows 10 & 11 Python version: 3.9 python-can version: Tried with 3.4 & latest 4.0rc python-can interface/s (if applicable): Vector CANcaseXL

[dpatel20]

According to this page:

You have a program that writes messages very quickly to the buffer so that the data rate of the real bus is exceeded (e.g. while-/for-loops).

Suggesting that the bus data rate needs to be respected to avoid this error.

Also, this comment suggests that the data is placed into a buffer (USB case) and returns - so it doesn't wait until message is actually placed on the bus before returning.

Can anyone suggest what might the appropriate way to respect the data rate of the bus?