How to receive DAQ stream when CAN ID of DTO buffer event channel differs from CTO buffer

[ilves]

Hello,

I notice some ECUs might send their DAQ stream in a different CAN ID than other messaging takes place (the event channel specific ID seems to be defined in XCP_ON_CAN -> EVENT_CAN_ID_LIST -> FIXED)

In this case, the method

Code: Select all

XCPApi.DequeuePacket(m_XcpSession, TXCPQueue.XCP_DTO_QUEUE, dtoBuffer, (ushort)dtoBuffer.Length)

will not be listening to the correct CAN ID as it is not the same as for CTO messaging.

Is there any way to overcome this restriction?

[ilves]

I guess I found some hint from old posts, I will try this out:

Hello,

first of all makes sure that you are using the last version, Version 2.2.1 from 2018-12-13, since older version had a problem receiving DTOs.

Note that you have to use the XCP_TransportLayerCommand so that dedicated DTOs can be included in the receiving filter. After this, dedicated DTOs can be read over the function XCP_DequeuePacket.

Here an extract of the help (TransportLayerCommand)
TransportLayerCommand.PNG

[ilves]

Following the previous thread, I do:

Code: Select all

byte[] daq_id = BitConverter.GetBytes(DAQ_ID);
XCPApi.TransportLayerCommand(m_XcpSession, 0xFD, daq_id, (byte)daq_id.Length, ctoBuffer, (ushort)ctoBuffer.Length);

But I still do not receive anything, although my CAN trace shows the DTOs are continuously streaming.

[ilves]

I guess I found some hint from old posts, I will try this out:

Hello,

first of all makes sure that you are using the last version, Version 2.2.1 from 2018-12-13, since older version had a problem receiving DTOs.

Note that you have to use the XCP_TransportLayerCommand so that dedicated DTOs can be included in the receiving filter. After this, dedicated DTOs can be read over the function XCP_DequeuePacket.

Here an extract of the help (TransportLayerCommand)
TransportLayerCommand.PNG

viewtopic.php?t=3055

[K.Wagner]

Hello,

if I understood well, you want to define different DAQ-Ids for several ECUs. This is possible and it is explined in the chapter "Introduction \ About XCP \ XCP on CAN". In short words, you can define one ID for each ECU to get DAQ messages. Having this like that, you should then get them over the Dequeue function.

XCP_DAQ.png (24.98 KiB) Viewed 4849 times

Hope to have helped you.

[ilves]

Hello,

if I understood well, you want to define different DAQ-Ids for several ECUs. This is possible and it is explined in the chapter "Introduction \ About XCP \ XCP on CAN". In short words, you can define one ID for each ECU to get DAQ messages. Having this like that, you should then get them over the Dequeue function.


XCP_DAQ.png


Hope to have helped you.

Hello,

My use case simply has one ECU. The A2L does not define a broadcast ID, so I guess it does not even support TRANSPORT_LAYER_CMD, as it was timeouting when calling the function you suggest.

But as mentioned in the first post, the A2L has a property EVENT_CAN_ID_LIST. In this case, when I start my freshly created dynamic DAQ list to some event channel, it will use the CAN ID defined in that property for the DTO stream, instead of the Slave ID used for CTO (CMD-RES) message exchange.

This means, my ECU uses three different CAN IDs for messaging, the slave CAN ID (CTO), CTO master CAN ID, and the slave CAN ID (DAQ). TRANSPORT_LAYER_CMD does not seem to be universally supported by ECUs.

I could for now solve this issue by calling "AddSlaveOnCan" two times - one with the (CTO) slave CAN ID and once with the DAQ event channel CAN ID. This way, it seems the DTO queue is receiving also from this other ID and not returning ERR_EMPTY_QUEUE. So I sort of configured two ECUs now... not sure if this is intentional use of the API, or is there another more generic way to change the message filtering of DequeuePacket() to receive from other CAN IDs than the slave ID (CTO), without assuming that TRANSPORT_LAYER_CMD would be supported by the ECU.

[K.Wagner]

Hello,

ok, as I see you have your solution. This is the more important.

Please note that we have implemented this API to comply with the official XCP specification. It provides—in the form of functions—all the services described in the XCP documentation. Furthermore, since our products operate using the CAN protocol, the `TRANSPORT_LAYER_CMD` command has been implemented. We do not read any A2L file, this happens in a higher level by the user. You parse the file and then configure the data down in the API, using the mentioned "services". Since we are no XCP-experts or give support on this protocol, we cannot evaluate this.

Your approach seems logical: your ECU responds with different identifiers to different queries, effectively behaving as more than one slave device. However, we cannot say whether this approach is valid or if could cause any problems in the communication, as we do not activelly use the protocol ourself.

We hope your workaround continues to function and that you can use it for your tasks.

[ilves]

For now it seems to work.

I believe to make the library more versatile to different uses cases and/or ECU implementations, it would be however a desired feature to somehow control the message-filtering configuration of the DTO queue.

If any future version of the API could easily implement that, maybe as a parameter to the TXCPProtocolLayerConfig, would be great.

[K.Wagner]

As previously mentioned, this is intended to be handled officially via the TRANSPORT_LAYER_CMD command. We are aware that this may not be implemented by all ECUs—whether because they are not 100% XCP-compliant or because they are designed for use with a protocol other than CAN.
Adding additional proprietary configuration runs counter to the goal of making the API more universal, which is the very core concept of XCP. Nevertheless, we will take your suggestion into account for future versions.

Thank you for your post and the workaround you found. This will help others facing a similar problem.