PEAK-System Forum

Hello,

I am using PCAN-USB Pro FD wih PCAN-Basic API. I want to trace all communication on CAN including transmitted by this channel. I want to use internal trace feature as you described me in my previous question: viewtopic.php?p=16440#p16440

However, everything seems to be right configured, but the trace file is always empty. What am I doing wrong?

I attach several screenshots to describe problem:
err_code.PNG - Used code in C++.
err_console.PNG - Console output.
err_trace.PNG - Empty trace file detection in file system.

Thank you in advance.

Ales

Hello,

Do you actively read on the bus once the trace is active?

The trace feature only works in confunction with can_read,
otherwise no traffic can be traced.
Please report back to us regarding this.

Best Regards

Marvin

Hello Marvin,

thank you, this was the problem. Now I am able to trace all messages.

I would like to ask one question to better understand the problem. I know from viewtopic.php?p=16440#p16440 that:
- Self sent messages cannot be read using "read" function because they are not placed into reception queue.
- Only way how to read self sent messages with PCAN Basic API is using this trace feature.

But then I don't understand, why should I call "read" periodically if the self sent messages are not in reception queue and cannot be returned by read?

Aleš

Hello Ales,

Let me try to get this as clear as possible:

-Self sent messages cannot be read using "read" function because they are not placed into reception queue.

Perfect timing for this remark. This used to be true but since PCANBasic 4.6.0 (released: DEC 10th 2021) the "PCAN_ALLOW_ECHO_FRAMES" allows
for TXFrames to be echoed into the Reception-queue.

Please see the new PCANBasic package and the corresponding Parameter documentation:

https://www.peak-system.com/fileadmin/m ... -basic.zip

But then I don't understand, why should I call "read" periodically if the self sent messages are not in reception queue and cannot be returned by read?

Because incoming messages could only be traced when read from the reception queue, the TX-messages were handled differently (They were available before being pushed to Hardware-TXqueue), as receive messages are physically pushed to HWRxqueue it is not possible to trace them before they have been pulled (read) from the queue. So to get any RxMessages actively reading the Rxqueue is required.

Best Regards

Marvin

Hello Marvin,

so If I understand it well, with the new version of driver, no turnaround is needed for tracing also TX messages (using PCAN-Basic API)? It would be great news for me.

Maybe I am dull, but still does not understand. I know, that "read" is pulling from RX queue and these messages is returned by this function. But how can be trace TX messages? If they are pushed to TX queue and send immediately, how can the API trace them into the file? Is it watching and logging all messages pushed/pulled to queues?

Best regards,

Ales

Hello Ales,

maybe i was a bit cryptic on this as i wanted to keep this as simple as possible:

The Trace-Feature has internal "echo-frames", which are read from the RxQueue
and then written to trace. I was not excluding the interal TX Echo Frames from the Trace function
but wanted to note the fact that reading the queue would be necessary reagardless of availability
of the TX-Frames.

Does this clear things up for you?

Please let me know.

Best Regards

Marvin

Hello Marvin,

ok, much clearer. Note that, I have tested the receiving echo frames. I am very glad that you have added this also to PCAN-Basic API (not only developer package) and no workarounds are not necessary to receive all communication programatically.

Thank you.
Ales