DTC cannot be read by valuecan

[ep081106]

hello Mr. Pier
from the issue :#12, i guess udsoncan can supprot the ValueCAN.
now when i read the DTC by ValueCAN, uedoncan can not get the response:
the interface is ：
bus = NeoViBus(bustype='neovi', channel=1, bitrate=500000) # value can / 581

udsoncan can sent the "19022F" to the ECU successful, and ECU responsed "[11 53]59 02 FF 06 07 41……" , but udsoncan reported an error "raise TimeoutException('Did not receive response in time. %s time has expired (timeout=%.3f sec)' % (timeout_name_to_report, timeout_value))
udsoncan.exceptions.TimeoutException: Did not receive response in time. P2 timeout time has expired (timeout=5.000 sec)"

the snapshot when read the DTC by ValueCAN

if i try to read the DTC by canaylzer, it works fine;

the snapshot when read the DTC by canaylzer

read to DTC.zip

could you please help me to check mine code where is wrong? thanks very much!

[pylessard]

Hi
Thanks for this information.
In order to debug more efficiently, we will need to identify if the issue is in udsoncan, can-isotp or python-can.

Since reading the DTC worked with Vector and only the Bus object changed, I would suspect python-can here.

Can you try reading raw messages with your Bus object? Also, if you enable global logging, you should get some logs from can-isotp as well and you will see if the TransportLayer receive the data.

I do not own a NeoVI interface, therefore I can't debug myself.

[ep081106]

hello,
i tried to changed the following code to find the log :
[logger_root]
level=NOTSET
handlers=consoleHandler,fileHandler
and the log is:
2019-07-09 15:52:44 [INFO] Connection: Connection opened
2019-07-09 15:52:44 [INFO] UdsClient: ReadDTCInformation<0x19> - Sending request with subfunction "reportDTCByStatusMask" (0x02).
2019-07-09 15:52:44 [DEBUG] Connection: Sending 3 bytes : [b'19022f']
2019-07-09 15:52:44 [DEBUG] isotp: Sending : <78A> (8) b'0319022f00000000'
2019-07-09 15:52:49 [DEBUG] Connection: No data received: [TimeoutException] - Did not receive frame from user queue in time (timeout=5 sec)
2019-07-09 15:52:49 [ERROR] UdsClient: [TimeoutException] : Did not receive response in time. P2 timeout time has expired (timeout=5.000 sec)
2019-07-09 15:52:49 [INFO] Connection: Connection closed

is it the right way to find the log?

log.zip

[pylessard]

The TransportLayer default logger name is "isotp", you can enable that logger in your config file.

[ep081106]

hello
tody i tried to chang "logging.conf" to save the log:
[loggers]
keys=root,UdsClient,Connection,UdsClient_unittest,Connection_unittest,isotp
……
[logger_isotp]
level=DEBUG
handlers=consoleHandler,fileHandler
qualname=isotp
propagate=0

the following is the log:

2019-07-11 14:23:22 [INFO] Connection: Connection opened
2019-07-11 14:23:22 [INFO] UdsClient: ReadDTCInformation<0x19> - Sending request with subfunction "reportDTCByStatusMask" (0x02).
2019-07-11 14:23:22 [DEBUG] Connection: Sending 3 bytes : [b'19022f']
2019-07-11 14:23:22 [DEBUG] isotp: Sending : <78A> (8) b'0319022f00000000'
2019-07-11 14:23:27 [DEBUG] Connection: No data received: [TimeoutException] - Did not receive frame from user queue in time (timeout=5 sec)
2019-07-11 14:23:27 [ERROR] UdsClient: [TimeoutException] : Did not receive response in time. P2 timeout time has expired (timeout=5.000 sec)
2019-07-11 14:23:27 [INFO] Connection: Connection closed

it sames like isotp didn't receive the data,

if i tried to read the DTC by vactor, the log is:
2019-07-11 14:21:22 [DEBUG] isotp: Receiving : <06F> (8) b'b84b04b04b007fe3'
2019-07-11 14:21:22 [INFO] Connection: Connection opened
2019-07-11 14:21:22 [DEBUG] isotp: Receiving : <0DB> (8) b'180034b000bffe23'
2019-07-11 14:21:22 [INFO] UdsClient: ReadDTCInformation<0x19> - Sending request with subfunction "reportDTCByStatusMask" (0x02).
2019-07-11 14:21:22 [DEBUG] isotp: Receiving : <06F> (8) b'5a4b04b04b007fe5'
2019-07-11 14:21:22 [DEBUG] Connection: Sending 3 bytes : [b'19022f']
2019-07-11 14:21:22 [DEBUG] isotp: Receiving : <0DB> (8) b'030034b000bffe25'
2019-07-11 14:21:22 [DEBUG] isotp: Receiving : <14A> (8) b'380002646400000a'
2019-07-11 14:21:22 [DEBUG] isotp: Receiving : <1C0> (8) b'0000000000000000'
2019-07-11 14:21:22 [DEBUG] isotp: Receiving : <248> (8) b'74b55dc800000008'

could you please check again? if you need more ,please tell me ,thanks

[pylessard]

Hi,
The first log shows that the isotp layer sent the message but received nothing.
The second log shows that nothing was sent.
In #31 you were able to read DTC with Vector, now you can't.

Something else is going on. I don't think this is a bug coming from either udsoncan nor can-isotp. I suspect something at the hardware level. Have you validated your bus usage? Is there error frames on your bus?

[ep081106]

log.zip

hi,

1. I could read the DTC by vector, if i didn't changed the "logging.conf" .
2. if i changed the "logging.conf" as i mentioned, and read the DTC by vector, the log will always displaying "isotp: Receiving" until i closed the IDLE (can be found in log.zip).
   i think my method to find the log is wrong , that's why i give the second log to you for reference.

i trid to read the DTC by value can / 581 in the vehicle, and i cannot find the DTC also.

anything you want ,i can try it in the vehicle, thanks

[pylessard]

Hi, I don't think the logging.conf has anything to do with the capacity of reading the DTC.
I don't know how to help you without a proper diagnostic of the problem.

Try sending raw messages without passing though UDS nor IsoTP and see if you can get an answer. Also, the logging you see s because your Python Can bus doesn't filter out messages not intended for IsoTP. The stack receives them, make a log entry and discard them. You can add such filter if you want to make your log cleaner and remove some load on the stack.

Also, since you have CanAnalyzer, look at your bus statistics to see the usage and check if you have error frames; that'll be a good start.

I will likely close this issue if we can't diagnose a little better what is going on. Right now, I am pretty convinced that udsoncan nor can-isotp are at the source of the issue.

REgards

[pylessard]

Hi,
I am closing this issue for now. Unless I get somethings that indicates that the problem originates from the UDS or IsoTP layer, I can't help much.

We can reopen if needed.
Cheers

[carlos0a]

@ep081106 hi, were you able to fix this issue? I just had the same behavior with neovi tool.