Getting timeout while sending 4KB packet over normal CAN about python-udsoncan HOT 19 CLOSED

Hi @wanam,
The timeout value you are changing is the timeout of the reception thread, it is not related to UDS P2 or P2* timeout. This is just the rate at which the thread polls the socket for new data. You shouldn't have to changes this value.

In your log, I doi not see the timeout error, but you mentioned that you got a P2 timeout which is defined by UDS, not Iso-TP. The UDS timeout is set here : https://github.com/pylessard/python-udsoncan/blob/master/udsoncan/client.py#L1488

Right now, the timeout to get a response from the server starts at the beginning of the transmission. Maybe this isn't correct, but I don't have the latest UDS standard at hand and timeout are defined in it. I have the 2006 version for now. I will double-check that as soon as I can.

You can overcome your limitation by modifying the UDS timeouts (there is 3 of them), refer to the documentation here : https://udsoncan.readthedocs.io/en/latest/udsoncan/client.html#request_timeout

Let me know if that helps.

from python-udsoncan.

Actually, your issue is possibly a duplicate of this issue : #42

Only reason why I do not work on it is the fact that I don't have the standard at hand yet.

from python-udsoncan.

from python-udsoncan.

I moved the issue to udsoncan as this is where the issue reside.

The issue is a little different than #42 , but the fix should be the same.
I will advise as soon as I can see what the standard has to say about timings.

from python-udsoncan.

Sorry for late reply, here are the logs of the send timeout (CAN-FD, stmin = 10, tx_dl=8, packet size = 4KB):

venv/lib/python3.7/site-packages/udsoncan/client.py:123: in decorated
    return func(self, *args, **kwargs)
venv/lib/python3.7/site-packages/udsoncan/client.py:802: in transfer_data
    response = self.send_request(request)
venv/lib/python3.7/site-packages/udsoncan/client.py:1469: in send_request
    self.conn.send(payload)
fota/fota_connections.py:354: in send
    self._connection.send(payload)
venv/lib/python3.7/site-packages/udsoncan/connections.py:52: in send
    self.specific_send(payload)
venv/lib/python3.7/site-packages/udsoncan/connections.py:303: in specific_send
    self.tpsock.send(payload)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <ISO-TP Socket: can0, [Normal_29bits - txid:0xXXXXXXXX, rxid:0xXXXXXXXX]>
args = (b'6\x01\xef\xbe\xad\xde\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x...\xe9\xf9\x00\x10Y\xc2\x04\x00\xe9\xf8\x01\x10\r\x00@\x02\x00\x00\x00\x00\x00\x00\x00\x80\r\x00@\x02\x00\x80\x0bT\x10',)
kwargs = {}

    def send(self, *args, **kwargs):
        if not self.bound:
            raise RuntimeError("bind() must be called before using the socket")
>       return self._socket.send(*args, **kwargs)
E       socket.timeout: timed out

venv/lib/python3.7/site-packages/isotp/tpsock/__init__.py:81: timeout

from python-udsoncan.

According to this preview of ISO 14229_1_2013 (page 8).
P2 client starts at the confirmation of request complete.

from python-udsoncan.

You are probably right, thank you.
Still, this may take some time to complete as it will involve some modification to the underlying layers.

from python-udsoncan.

I tried to do some troubleshooting to understand this issue, changed the overall time to cover only the reception time: wanam@6c3d069 , so that we avoid to report the P2 timeout while the client is still sending.

We still need to remove (or increase) the socket's timeout for send case, unfortunately it is still unclear for me why the socket returns early and reports sending all the 4kb data, while the data is still buffering on the underlying layers, as seen on the isotp kernel module.

I tried the select way (like on the socketcan here), but it didn't help.

from python-udsoncan.

You don't need to play with the socket timeout. The socket is non-blocking. Everything relies on the UDS timeout which, as I said, start timing from the beginning of transmission. For now, the best you can do is make the UDS timeouts big enough

from python-udsoncan.

I'm surprised because if I recall during my previous debugging, I tried to force it to blocking and when I read the blocking flag of the socket I see it set to blocking while sending the data.
Will increase the timeout for now, thank you for your support.

from python-udsoncan.

Hello @pylessard , wondering if you had time to take a look at this issue?
We are still not able (without increasing sending timeout) to send 4k packets with 0x36 service over normal CAN (8 bytes).

from python-udsoncan.

Hi @wanam ,
I did look. It is a bit tricky. I am willing to change that behaviour, but this will need to be done in all Connections. I cannot make this happens with the IsoTP Kernel driver unless @hartkopp update the driver to give a mean of knowing when the transmit buffer is empty (possibly with blocking sockets).

Right now I am keeping the project as it is, if I get the possibility to update the behaviour everywhere, I will do so.

Regards

from python-udsoncan.

Hi @pylessard and @wanam ,

I'm currently on vacation and rebuilding my kitchen - so my thoughts are currently far away from programming, which might have helped now ;-)

I added this patch hartkopp/can-isotp@792bad1 on the 4.17+ branch which is intended for Linux mainline posting.

The patch should be applicable to the master branch too. I'll test it in the evening as I have to head back to my construction site now.

from python-udsoncan.

Hi @hartkopp ,

I have just tested your patch and it works fine, the patch is not fast-forward merging, I merged it on my fork:
wanam/can-isotp@216a4b1

I had to make 2 changes on pythons libs:

• Declare the new option on python can-isotp: wanam/python-can-isotp@30d4b57
• Start the receiving timer after send completion on udsoncan lib:
  wanam@756b91a

And according to my tests it takes up to 6 seconds to complete the send of 4KB data over normal CAN with stmin = 10ms.

Thanks again to both of you.

from python-udsoncan.

That's great! Thanks @wanam for real world testing!!

@pylessard : would you like to do some testing too before I add this extension to the master branch?

from python-udsoncan.

@hartkopp : Go ahead, don't wait on me. Thank you for your support on this!

@wanam : I will check to fix this as soon as I can. I don't have much free time ( I am not rebuilding my kitchen, but 2 kids that don't like to sleep and a job is quite enough).

from python-udsoncan.

@pylessard same situation with my 2 kids 😅, good luck.

from python-udsoncan.

Can I close this?

from python-udsoncan.

Yes, it should be okay now.

from python-udsoncan.