PEAK-System Forum

Hello,
I'm trying to use dynamic DAQ lists with the XCP-API. Unfortunately I encounter a runtime error: Sometimes it works without any problems and I get cyclic messages containing memory readouts according to the configured lists. But sometimes - especially while creating ODT entries - the program get stuck when waiting for the XCP response.
The function receiveNextCanMessageWithID() is implemented the following way:
The program sometimes get stuck in the loop utilizing the PCANBasic.Read(...). Even if I ignore the message ID in the loop condition, it does not work. The Read-function always returns TPCANStatus.PCAN_ERROR_QRCVEMPTY in this scenario. So I attached a second CAN interface to the bus. There I can see the positive response of the XCP command. So the message I'm looking for is on the bus. But sometimes, it is not in the PCAN receive buffer. How can it be?

Thanks in advance.

Hello,

please note that using the PCAN-Basic API to read messages from the same CAN channel used by PCAN-XCP API (or any other high-layer protocol that uses PCAN-Basic for communication) shuld not be done, since there is only one receive queue to read from. This means, when one API reads a message, that message is not available for the other API anymore. This is particulary destructive for the communication of high-layers protocol like XCP. If you want to do any check on the communication with PCAN-Basic, then use a separated physical CAN channel for it.

As I can see, you are using the asynchronous version of WriteDAQListEntry. Please note that for getting any asynchronous generated CTO/DTO, you need to use the method DequeuePacket. Please check the documentation on this method and also the chapter "Introduction/About PCAN-XCP/Synchronpus vr. Asynchronous Package Receiving", for more information about receiving asynchronous messages.

Thanks for fast response!

Now I use the synchronous command versions for the DAQ setup, which works perfectly. For receiving DTO's I now use DequeuePacket(...) instead of Read(...). This brings me to another problem: How can I determine the Length of the CanMessage? The Read(...) function returns the LEN attribute inside the CANMsg out-parameter. Is there a similar one in DequeuePacket(...)? If so, I cannot find it.

Hello,

if you read the API documentation you will see, that the length of packages depends on the configuration of your ECU. As stated in the documentation of the Connect method, after connecting your application, the size of CTOs and DTOs ist set as requested by the ECU. You receive this information on the command response.

The length of any further message is then calculated using these values and the information for each command response within the XCP protocol.

Please note that we encourage API users to read and understand the documentation before starting a project from scratch, as we do not offer support for the protocol itself.

Thanks for your understanding,