Hi everyone,
I'm using UDS_Svc[...]_2013 and UDS_WaitForService_2013 functions to communicate with an ECU.
In my case the server ignores the flow control frame and does not send consecutive frames if the flow control is send to fast after receiving the first frame. I currently just repeat the request until flow control frame is send >1ms after first frame, which causes the server to transmit the whole response as expected.
Is there a way to set a minimum time gap between receiving a first frame and sending a flow control frame?
I looked through PCAN-UDS 2.x API User Manual and couldn't find anything. Also viewtopic.php?t=1332 doesn't give me much hope.
Cheers,
Larry
Delaying flow control after receiving first frame
-
- Posts: 2
- Joined: Wed 22. Jan 2025, 16:58
-
- Software Development
- Posts: 305
- Joined: Mon 9. Sep 2013, 12:21
Re: Delaying flow control after receiving first frame
Hello,
There is no parameter to instruct the API to slow down the transmission of a Flow Control Frame in response of an ISOTP First Frame.
If I understand correctly, your ECU has either difficulties handling fast CAN traffic or expecting a separation time minimum between his First Frame and a Flow Control.
Unfortunately the Separation Time Minimum (defined in ISO-15765-2) is the minimum time the sender is to wait between transmission of two Consecutive frames.. It should not monitor Flow Control frames.
Is the ECU a component developed internally? If yes I would recommend to analyse why the FC frames are ignored by the ECU.
There is no parameter to instruct the API to slow down the transmission of a Flow Control Frame in response of an ISOTP First Frame.
If I understand correctly, your ECU has either difficulties handling fast CAN traffic or expecting a separation time minimum between his First Frame and a Flow Control.
Unfortunately the Separation Time Minimum (defined in ISO-15765-2) is the minimum time the sender is to wait between transmission of two Consecutive frames.. It should not monitor Flow Control frames.
Is the ECU a component developed internally? If yes I would recommend to analyse why the FC frames are ignored by the ECU.
Best regards,
Fabrice
Fabrice
-
- Posts: 2
- Joined: Wed 22. Jan 2025, 16:58
Re: Delaying flow control after receiving first frame
Hi Fabrice,
thanks for your answer.
You got that correct. The ECU has either difficulties handling fast CAN traffic or is expecting a separation time minimum between his First Frame and a Flow Control.
Unfortunately the ECU is developed by a third party, so I don't have any insight on why the FC frames are ignored by the ECU if they are sent too fast after the first frame.
Since instructing the API to slow down the transmission of a Flow Control Frame in response of an ISOTP First Frame is not possible, I will reach out to the manufacturer of the ECU.
Cheers,
Larry
thanks for your answer.
You got that correct. The ECU has either difficulties handling fast CAN traffic or is expecting a separation time minimum between his First Frame and a Flow Control.
Unfortunately the ECU is developed by a third party, so I don't have any insight on why the FC frames are ignored by the ECU if they are sent too fast after the first frame.
Since instructing the API to slow down the transmission of a Flow Control Frame in response of an ISOTP First Frame is not possible, I will reach out to the manufacturer of the ECU.
Cheers,
Larry