asc file parse failed

[dufengit]

Describe the bug

asc_msg = next(asc_iter, None)

File "D:\ProgramData\Anaconda3\envs\qt_env\lib\site-packages\can\io\asc.py", line 131, in iter
frame.append(int(byte, 16))
ValueError: invalid literal for int() with base 16: 'Length'

To Reproduce

I replay the asc file use CANoe, find there is Can overload Frame。And when the error raised, the DLC is 13. I don't know if this 13 DLC is affected by Can overload Frame or not.
['C2', '4A', '05', '81', '00', '00', '15', '10', 'Length', '=', '225910', 'BitCount', '=', '117', 'ID', '=', '545']
8
['55', 'AA', '01', '02', '03', '04', '05', '06', 'Length', '=', '229910', 'BitCount', '=', '119', 'ID', '=', '1023']
13
asc_msg = next(asc_iter, None)
File "D:\ProgramData\Anaconda3\envs\qt_env\lib\site-packages\can\io\asc.py", line 131, in iter
frame.append(int(byte, 16))
ValueError: invalid literal for int() with base 16: 'Length'

Expected behavior

Can parse asc file in any condition

Additional context

OS and version: win10
Python version:3.8.5
python-can version:3.3.4
python-can interface/s (if applicable):

Traceback and logs

def func():
    return "hello, world!"

[dufengit]

and the is_fd flag is False

[zariiii9003]

Can you try with python-can version 4? A properly formatted traceback would be helpful.

[dufengit]

I upgrade my package to version 4.0.0, and now the error msg is like this:
D:\ProgramData\Anaconda3\envs\qt_env\python.exe C:/Users/qiao/Desktop/analy_tool_v1.3/convert/asc_csv.py
start
Traceback (most recent call last):
File "C:\Users\qiao\Desktop\analy_tool_v1.3\convert\asc_csv.py", line 139, in
asc_msg = next(asc_iter, None)
File "D:\ProgramData\Anaconda3\envs\qt_env\lib\site-packages\can\io\asc.py", line 305, in iter
msg = self._process_classic_can_frame(rest_of_message, msg_kwargs)
File "D:\ProgramData\Anaconda3\envs\qt_env\lib\site-packages\can\io\asc.py", line 207, in _process_classic_can_frame
self._process_data_string(data, dlc, msg_kwargs)
File "D:\ProgramData\Anaconda3\envs\qt_env\lib\site-packages\can\io\asc.py", line 171, in _process_data_string
frame.append(int(byte, self._converted_base))
ValueError: invalid literal for int() with base 16: 'Length'

[dufengit]

python version used actually is 3.9.7, in fact, i tried both 3.8.5 and 3.9.7

[zariiii9003]

Can you share your asc file or the lines which cause this error?

[dufengit]

I checked with my colleague, there is some issue when the ecu is sending can msg, this should not be issue of can package, you can close this issue, thanks

[hartkopp]

At least a DLC of 13 would be ok. Even with Classical CAN (CAN2.0B). The CAN controller is only transferring 8 bytes but the value inside the DLC field might get up to 15 (0xF) which is also transferred over the CAN bus and can bee seen in the receiving CAN controller.

@dufengit Having a short log file (e.g. only 2 or 3 line) would help to make the ASC file parser more robust. Can you still provide some example log file snippet even though your concrete problem seems to be solved?

[dufengit]

Logging2022-04-28_10-44-52.zip
you can try this file

[dufengit]

I add one condition, to check the real length use index of 'Length' string in data

[hartkopp]

I add one condition, to check the real length use index of 'Length' string in data

In the python-can code?

Would it make send, that you clone python-can to your personal GitHub repos, do the change and send a pull-request for a review?

This is the usual way to fix problems and to attribute the right reporter and author of the patch ;-)

[dufengit]

I add three line code as below in asc.py, line 169 , to judge if the real length is equal to data_length. Just work for my case
length_index = data.index('Length')
if(data_length != length_index):
data_length = length_index
I don't know if there is other constraints.

[hartkopp]

Hm, when the ìs_fd flag is false, the number of handled CAN data bytes should be limited to a maximum of 8.

As stated above the DLC value might be higher than 8 but the number of data bytes for non-FD frames is always limited to 8.