Page 1 of 1

Time of send data

Posted: Mon 23. Jul 2018, 13:59
by KateS
Hello,
I'm currently developing a tester using your APIs and I have some question about methods in PCAN_UDS.dll.
I'm sending Calibration Data with SvcTransferData() and then waiting for response from ECU with WaitForService().
Measured working time is in twice of much as in other program (vFlash CANape). Every WaitForService takes about 4-5ms an average, all transfer takes about 10 minutes. Because code .dll is hidden from me, I want to ask what is really going on in WaitForService() and which parameters can affect the waiting time.

Best Regards,
Katerina

Re: Time of send data

Posted: Tue 24. Jul 2018, 10:00
by F.Vergnaud
Dear Katerina,

By default PCAN-UDS API uses a value of 10ms for the ISO-TP parameter "Minimum Separation Time" (STmin). You can reduce this value to speed up the communication of fragmented CAN messages by using the function UDS_SetValue with the parameter PUDS_PARAM_SEPERATION_TIME.

Code: Select all

        TPUDSCANHandle Channel;
        ...
        BYTE param = 0;  // 0, disables the minimum separation time (0xF1 to 0xF9 are respectively 100µs to 900µs)
	TPUDSStatus status = UDS_SetValue(Channel, PUDS_PARAM_SEPERATION_TIME, &param, sizeof(param));
        ...
Otherwise the WaitForService waits for UDS messages with a polling resolution of 1ms using the UDS_Read function, it also includes and handles other mechanisms like session diagnostic management and extended timing response (the ECU requests more time to precess the request).

Re: Time of send data

Posted: Wed 11. Dec 2019, 15:18
by vacs.actia
Dear Fabrice,
I'm facing the same issue than Katerina when using the SvcTransferData function. It seems that updating the PUDS_PARAM_SEPERATION_TIME parameter have no impact on the sequence of fragmented CAN messages (always 10ms per frame).
I have tried to increase the value of this parameter to check the effect but the result is the same : 10ms/CAN frame.

Is this parameter still active? How can I improve this behaviour?

EDIT:
The problem was linked to the ECU as explain in the following old post:
F.Vergnaud wrote:Hello Alexis,

Actually your result are consistent: with ISO-TP (and therefore UDS) it is the receiver (i.e. the ECU) that defines the value of the SEPERATION_TIME and BLOCK_SIZE to use. Here is a small description of the communication:

Code: Select all

      
1  169.417 07E0  10 34 36 01 41 42 43 44  <-- UDS Tester Client, requesting a transfert data
2  170.415 07E8  30 0A 0A 55 55 55 55 55  <-- ECU responding with STMin=0x0A, Block Size=0x0A
3  182.172 07E0  21 45 46 47 48 49 4A 4B 
4  192.874 07E0  22 4C 4D 4E 4F 50 51 52  <-- Tester Client uses the values given by the ECU
5  203.633 07E0  23 53 54 55 56 57 58 59 
Check the configuration of your ECU or post your CAN trace of the beginning of the communication so that we can tell you what its configuration is.

Re: Time of send data

Posted: Wed 11. Dec 2019, 15:30
by F.Vergnaud
Dear vacs.actia,

Have you checked the return status of your function UDS_SetValue?
Also you can check that the value was correctly set by calling UDS_GetValue with parameter PUDS_PARAM_SEPERATION_TIME.

Finally can you tell us what version of PCAN-UDS and PCAN-ISO-TP APIs you are using?
Thank you

Re: Time of send data

Posted: Wed 11. Dec 2019, 15:50
by vacs.actia
Dear Fabrice,
Thanks for your answer. In the mean time, I have found the root cause of my problem: the problem was due to the ECU parameters.
As said in you 2017 post :
F.Vergnaud wrote:Hello Alexis,

Actually your result are consistent: with ISO-TP (and therefore UDS) it is the receiver (i.e. the ECU) that defines the value of the SEPERATION_TIME and BLOCK_SIZE to use. Here is a small description of the communication:

Code: Select all

      
1  169.417 07E0  10 34 36 01 41 42 43 44  <-- UDS Tester Client, requesting a transfert data
2  170.415 07E8  30 0A 0A 55 55 55 55 55  <-- ECU responding with STMin=0x0A, Block Size=0x0A
3  182.172 07E0  21 45 46 47 48 49 4A 4B 
4  192.874 07E0  22 4C 4D 4E 4F 50 51 52  <-- Tester Client uses the values given by the ECU
5  203.633 07E0  23 53 54 55 56 57 58 59 
Check the configuration of your ECU or post your CAN trace of the beginning of the communication so that we can tell you what its configuration is.
Best regards