PEAK-System Forum

Hello,

when I trigger the initialization of an physical interface on the PCAN-USB X6 with a call to CAN_ConnectToNet or CAN_SetParam(<Bitrate>) this results in blocking out other threads that are writing to and reading from any other of the 5 remaining interface for about 20 milliseconds. I suppose this is due to a shared Mutex inside the API.

I am using the CANAPI4 Beta.

Question: Will the CANAPI4 Release fix this issue? (20 milliseconds are a long time in which 400 CAN FD messages with 1 byte payload and 1/8 MBit/s may by received)

Kind regards
Martin Mödlinger

Hello,

yes, you are right, the API DLL uses a mutex object to serialize the API calls. But this mutex object is not responsible for the delay. During CAN_ConnectToNet() and during CAN_SetParam(bitrate) the CAN controller in the hardware is reconfigured, which is done in a series of configuration commands, each requiring certain USB transactions. Since the API call into the driver via DeviceIoControl() returns only when the whole procedure is finished, any other thread will be blocked in the meantime. Removing the mutex object would not change anything because the DeviceIoControl() call itself is serialized over all threads and processes.

Even if hundreds of FD messages are received during this 20 ms delay, the receive queue is large enough to buffer all the data, nothing is lost.

I have done some tests, a time delay was only measureable for USB-based hardware. For PCI Express cards, the configuration process is much quicker.

Hello,

thanks for the explanation. PCI Express is not usable in my application. I have to stick to the PCAN-USB X6. Therefore I will take the delay as granted for now.

If you find out any way to get rid of the delay I would appreciate if you let me know.

Kind Regards
Martin