Allow requesting a did without decoding it

[philippoo66]

could please somebody advice?!

I'm trying to read long data over vcan0 (so a bit slow) and

    response = client.send_request(
        udsoncan.Request(
            service=ReadDataByIdentifier,
            data=(did).to_bytes(2, byteorder='big')
        )
    )

returns before data transmission has finished (always after 1 second) :-(

My latest attempt was

    config = dict(udsoncan.configs.default_client_config)
    config['request_timeout'] = 3

    with Client(conn, config=config) as client:

but that did not change anything.

before I tried

        conn = IsoTPSocketConnection(can, rxid=rx, txid=ecutx, timeout=3)

and

    with Client(conn, request_timeout=3) as client:

but nothing took effekt - always returned after 1 second.

I tried 'timeout' and 'request_timeout', I tried 3 and 3000 - alway no effect.

How should I do?

thank you!!

[philippoo66]

ok, I think I got it...
config['p2_timeout'] = 3
worked.

[philippoo66]

and now the next question:
config['exception_on_negative_response'] = False
has no effect. I'm still getting "ReadDataByIdentifier service execution returned a negative response ConditionsNotCorrect (0x22)" - what am I doing wrong now?

[pylessard]

Hi
send_request is an internal method of the client, not meant to be used by the user.
Use read_data_by_identifier instead. Look at this example, much cleaner than what you did.

https://udsoncan.readthedocs.io/en/latest/udsoncan/examples.html#reading-a-did-with-readdatabyidentifier

You can find the reason of your issue here: https://github.com/pylessard/python-udsoncan/blob/master/udsoncan/client.py#L404
Each user exposed methods are decorated with @standard_error_management, applying the configuration rules.

[philippoo66]

Good morning Pier-Yves,

thank you very much for your fast reponse! In our 'main application' we are using the user-exposed read_data_by_identifier and it is working very well and comfortably. But as far as I understood, this method requires a codec which might be a raw codec but which postulates the awareness of the data length?

In my current case this is a scan application where we do not know if the requested datapoint even exists, and if it does, how many bytes it will return. So I used the mentioned solution found by @surt91 (thank you Hendrik!!)

Is there a better way to do this (find out the data length and the existence)?

[pylessard]

Hmm, I see
There is no method to request a DID without reading it.
There is a non-standard trick requested by a user a while ago that I implemented. I assume he was trying to do the same as you.
You can raise a special exception in the codec length function. The parser will receive that and consume the whole payload. Obviously, you can't do that when reading many DIDs in random order.

https://udsoncan.readthedocs.io/en/latest/udsoncan/helper_classes.html#didcodec

Maybe I could add a peek method that request a DID without decoding the response. That would be cleaner I think

[pylessard]

On the other hand, you can send the raw request/response yourself, but you will loose some intelligence implemented by the client, like timeout handling and "busy" response handing

Something like this could do (not tested)

dummy_did_config = {
    0x123:'h'   # Dummy codec.  No decode/encode actually happens while crafting the request.
}

req = services.ReadDataByIdentifier.make_request(0x123, dummy_did_config)
conn.send(req)
data = conn.wait_frame(timeout=5)
response = Response.from_payload(data)
# No call to ReadDataByIdentifier.interpret_response().  No decoding of the did happens, so we're good.
if response.positive:
    print("did exist")

[philippoo66]

thank you! I will give that a try when I will find some time. Currently I'm trapping the negative response exception and am fine with Hendriks solution so far. thank you again very much for your support!!

[pylessard]

Want to try this branch?
https://github.com/pylessard/python-udsoncan/tree/allow-peek-did

response =  client.test_data_identifier(0x1234)

response.service_data will be None because the response is not parsed

[philippoo66]

Hi Pier Yves!

Thank you for the work! As soon as possible I will give it a try (right now I have to do some work 'for money'. far behind with...).

Greetings!
Phil

[pylessard]

I might merge anyway. The feature seems enough.
Reopen if you think it is necessary

[pylessard]

Fixed in #204