PEAK-System Forum

Dear Support Team,

we have a PC-Applikation using PCAN-Basic.dll and PCAN-UDS.dll.
As concurrent Use is not possible, we switch between the two, which makes the whole application a lot more complex.

We need to read a lot of data from CAN with as much "real time" tracing as possible.
UDS is used to to read some Data By ID stuff.

Currently we are facing the issue that whenever the UDS is active, CAN Basic is not usable. We are loosing quite some messages.
Thus we have reduced the UDS interval, increasing latency for the Read Data By ID stuff.
In certain situation this is no longer acceptable.

Is there any way to get a second Rx-Queue working so we can use UDS and Basic concurrent?
At least it is possible, to use the same USB-CAN interface inside our application side by side with the CAN-Monitor.
In CAN-Monitor no messages are lost while UDS is active as it is inside our application.

Is there anything possible to NOT loose basic frames when UDS is active?
Is it possible to extend the UDS.dll with an outlet rx-queue that aggregates all CAN-messages that are of no interest to UDS.dll?

As the UDS.dll does work very well, i really don't like the Idea to throw it out and implement my own minimal-set.
Your UDS.dll was our main-reason to switch from Vector to Peak. But the savings from this switch are eaten away fast by the increasing complexity the drawbacks are creating.

Kind regards
Clemens

Hello Clemens,

The feature you are describing is implemented in PCAN-UDS 2.x:
- PCAN-UDS connects to PCAN-ISO-TP 3.x and only digests UDS messages,
- any CAN/CANFD frames or ISO-TP messages that are not processed by the UDS API are left in the Rx queue of PCAN-ISO-TP API and are available with the CANTP_Read function.

You can check the exemple 08_read_write_uds_and_isotp included in the UDS package, which shows a concurrent communication between UDS and ISOTP.
The mechanism is quite similar for raw CAN/CAN-FD frame.
The main difference will be that, instead of defining the ISOTP mappings you'd like to communicate with, you will have to disable the filtering of CAN IDs:
- PCAN-UDS enables by default, in PCAN-ISO-TP, the white filtering of CAN IDs that only correspond to its UDS mappings (it speeds up the processing of CAN frames on bus with an heavy bus load).
- After the initialization of you UDS channel, call CANTP_SetValue with the parameter PCANTP_PARAMETER_FILTER_CAN_ID and a value of 0.
- You will be able to receive (non-UDS) CAN frames via PCAN-ISO-TP and its function CANTP_Read.
- Note that it is also possible to receive a copy of the segmented frames of an UDS message (set parameter PCANTP_PARAMETER_KEEP_HIGHER_LAYER_MESSAGES to 1), this can be useful for debugging purpose.

Hi Fabrice,

thanks for your hint. It works like a charm.
Only some small changes were needed.

Receiving CAN Basic messages is now done using CANTP_Read_.
Transmitting did not need any changes, so is still done with CAN_Write.

I was able to remove all extra handlings like switching between Basic and UDS.
The UDS read interval also increased much along the way.
Now we are as Realtime as we want/can be.

Could not be happier, thanks very much.

Kind regards
Clemens