Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect Payload Parsing in 64-Byte CAN FD Frames from BLF Files Using python-can #1905

Open
ppd2mmb opened this issue Dec 31, 2024 · 2 comments · May be fixed by #1906
Open

Incorrect Payload Parsing in 64-Byte CAN FD Frames from BLF Files Using python-can #1905

ppd2mmb opened this issue Dec 31, 2024 · 2 comments · May be fixed by #1906
Labels

Comments

@ppd2mmb
Copy link

ppd2mmb commented Dec 31, 2024

Describe the bug

I encountered an issue when using python-can to parse BLF files. Specifically, when parsing BLF files generated by certain tools(Tsmaster), I observed incorrect payload data in 64-byte CAN FD frames. The problem consistently appears starting at 48 bytes. However, the same BLF files can be parsed correctly using Tsmasterand CANoe.
CANoe:
image

python-can:

image

Please investigate this issue. Thank you!

To Reproduce

I have attached the BLF file.
2024_12_31_14_09_35.zip

from can import BLFReader
import sys
def read_blf(file_path):
    try:    
        with BLFReader(file_path) as reader:
            for msg in reader:      
                if msg.arbitration_id== 0x6a9:
                    print("***********************************")
                    print(f"Raw Data: {msg.data.hex()}")             
                    print(f"Timestamp: {msg.timestamp} s")
                    print(f"Channel: {msg.channel}")
                    print(f"ID: {hex(msg.arbitration_id)}")
                    print(f"Data: {msg.data.hex()}")
                    print(f"Length: {msg.dlc}")
                    print("-" * 50)
                    print("***********************************")
    except Exception as e:
        print(f"read BLF file error: {e}")

if __name__ == "__main__":
    if len(sys.argv) != 2:
        sys.exit(1)
    blf_file = sys.argv[1]
    read_blf(blf_file)

Expected behavior

Additional context

OS and version: windows 11
Python version:Python 3.11.9 (tags/v3.11.9:de54cf5, Apr 2 2024, 10:12:12) [MSC v.1938 64 bit (AMD64)] on win32
python-can version:4.5.0
python-can interface/s (if applicable):

@ppd2mmb ppd2mmb added the bug label Dec 31, 2024
@zariiii9003
Copy link
Collaborator

zariiii9003 commented Jan 1, 2025

Thank you for the code snippet and example file 👍

I checked the first message object in your file. The mValidDataBytes field has a value of 64, but the object only contains 48 data bytes. This causes python-can to read parts of the next object.
This is a bug in TSMaster, but the python-can implementation could be more robust, too.

Edit: Like CANoe, binlog.dll also adds padding with 0x00 bytes, so maybe this is valid according to blf format...

@zariiii9003 zariiii9003 linked a pull request Jan 1, 2025 that will close this issue
@ppd2mmb
Copy link
Author

ppd2mmb commented Jan 2, 2025

Thank you for the code snippet and example file 👍

I checked the first message object in your file. The mValidDataBytes field has a value of 64, but the object only contains 48 data bytes. This causes python-can to read parts of the next object. This is a bug in TSMaster, but the python-can implementation could be more robust, too.

Edit: Like CANoe, binlog.dll also adds padding with 0x00 bytes, so maybe this is valid according to blf format...

Thank you for your response and quick fix. I have downloaded the updated script and successfully read the payload. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants