[Ovmsdev] OBD/UDS error 31

[Michael Balzer]

sharkcow,

I would assume…

> or which attempts to access a dataIdentifier/routineIdentifer that is
> not supported or *not supported in active session*. 

…you need to login with a diagnostic session first. Look for
VEHICLE_POLL_TYPE_OBDIISESSION (0x10) requests.

Regards,
Michael


Am 03.10.20 um 20:23 schrieb sharkcow:
> Michael,
>
> thanks for the explanation.
>
> Still I'm wondering why the same command works when issued from the
> third-party OBD adapter... are there any setup commands I could look out
> for?
>
> sharkcow
>
>
> Am 03.10.20 um 20:08 schrieb Michael Balzer:
>> sharkcow,
>>
>> 0x22 is VEHICLE_POLL_TYPE_OBDIIEXTENDED and well supported, see vehicle
>> module.
>>
>> See the PDF I just sent you on page 252:
>>
>> Error code 0x31:  requestOutOfRange
>>
>>> This response code indicates that the requested action will not be
>>> taken because the
>>> server has detected that the request message contains a parameter
>>> which attempts
>>> to substitute a value beyond its range of authority (e.g. attempting
>>> to substitute a
>>> data byte of 111 when the data is only defined to 100), or which
>>> attempts to access a
>>> dataIdentifier/routineIdentifer that is not supported or not supported
>>> in active session.
>>> This response code shall be implemented for all services which allow
>>> the client to
>>> read data, write data or adjust functions by data in the server.
>>
>> Regards,
>> Michael
>>
>>
>> Am 03.10.20 um 14:59 schrieb sharkcow:
>>> I'm having trouble getting a multiline OBD message to be read by OVMS.
>>> What exactly does error code 31 mean?
>>>
>>> In the OVMS log I see:
>>>
>>> D (806212) vehicle: PollerSend(0): send [bus=1, type=22, pid=1821],
>>> expecting 713/77d-77d
>>> D (806222) vehicle: PollerReceive[77D]: process OBD/UDS error 22(1821)
>>> code=31
>>>
>>> The only messages with header 713 and 77D in the CAN log are:
>>>
>>> 1601729078.788373 1T11 713 03 22 18 21 00 00 00 00
>>> 1601729078.801032 1R11 77D 03 7f 22 31 aa aa aa aa
>>>
>>> However, when I log with OVMS what happens when a working third-party
>>> OBD-adapter issues the command, I see:
>>>
>>> 1601721047.201952 1R11 713 03 22 18 21 55 55 55 55
>>> 1601721047.210050 1R11 77D 10 2f 62 18 21 01 fe 00
>>> 1601721047.210695 1R11 713 30 ff 01 55 55 55 55 55
>>> 1601721047.214801 1R11 77D 21 00 16 15 00 00 02 20
>>> 1601721047.219865 1R11 77D 22 00 00 00 04 00 00 00
>>> 1601721047.224808 1R11 77D 23 00 00 00 15 91 00 00
>>> 1601721047.230282 1R11 77D 24 01 66 00 00 00 00 00
>>> 1601721047.235039 1R11 77D 25 00 00 00 00 fe c9 c9
>>> 1601721047.240117 1R11 77D 26 c9 c9 ff fe ff ff aa
>>>
>>> Does OVMS even support multiline OBD messages? Are there any settings I
>>> should adjust? Any clues? :)
>>>
>>> I'm guessing the intermediate "713 30 ff 01" an acknowledge for the
>>> multiline response, does/can OVMS send that?
>>>
>>> Thanks for any hints!
>>>
>>> sharkcow
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201003/92746fbe/attachment-0002.htm>