Dynamic DAQ lists - runtime error

A free API for the communication with control units based on the Universal Measurement and Calibration Protocol (XCP) by ASAM for Windows®
Post Reply
User95
Posts: 2
Joined: Tue 23. Aug 2022, 10:53

Dynamic DAQ lists - runtime error

Post by User95 » Tue 23. Aug 2022, 11:19

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.

Code: Select all

/* ... */
XCPApi.WriteDAQListEntry(m_XcpSession, entry);
receiveNextCanMessageWithID(0x202);
/* ... */
The function receiveNextCanMessageWithID() is implemented the following way:

Code: Select all

private TPCANMsg receiveNextCanMessageWithID(uint msgID)
{
  TPCANMsg CANMsg;
  TPCANTimestamp CANTimeStamp;
  TPCANStatus stsResult;             

  do
  {
    stsResult = PCANBasic.Read(handle, out CANMsg, out CANTimeStamp);
  }while(stsResult == TPCANStatus.PCAN_ERROR_QRCVEMPTY || CANMsg.ID != msgID);

  return CANMsg;
}
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.

K.Wagner
Software Development
Software Development
Posts: 1080
Joined: Wed 22. Sep 2010, 13:36

Re: Dynamic DAQ lists - runtime error

Post by K.Wagner » Tue 23. Aug 2022, 11:58

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.
Best regards,
Keneth

User95
Posts: 2
Joined: Tue 23. Aug 2022, 10:53

Re: Dynamic DAQ lists - runtime error

Post by User95 » Tue 23. Aug 2022, 14:44

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.

K.Wagner
Software Development
Software Development
Posts: 1080
Joined: Wed 22. Sep 2010, 13:36

Re: Dynamic DAQ lists - runtime error

Post by K.Wagner » Tue 23. Aug 2022, 15:38

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.
MAX_CTO and MAX_DTO values
MAX_CTO and MAX_DTO values
XCP_Connect.PNG (53.54 KiB) Viewed 2938 times

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,
Best regards,
Keneth

Post Reply