Missing Data, Questionable Arbitration IDs when using PCBUSB with python-can notifier

[trey-sygnalauto]

Uwe,

I am seeing some unexpected behavior when using your library with python-can. Your monitor tool has an output like this (which looks correct):

./pcbusb_recv
Initialize CAN: 0x0
  - R ID: 601 LEN:8 DATA:63 00 00 00 63 a5 d0 01
  - R ID: 602 LEN:8 DATA:63 00 ff ff ff ff ff ff
  - R ID: 603 LEN:8 DATA:63 00 01 00 00 00 02 00

When I rx these same messages in python the arb ID is way different but the lower bytes are correct:
msg.arbitration_id = 27874818787378690 = 0x63080000000602

The message also only contain an empty byte array for data and has a dlc of 255.

Following the message up the call stack in python, it never appears to have the right data so I though I would reach out to you.

Not sure how to debug from here since the library doesn't have sources. Please help! :)

[mac-can]

Thanks for your report and for comparing the output with pcbusb_recv.

The output from pcbusb_recv shows that libPCBUSB delivers correct CAN frames (IDs 601–603, DLC = 8, and the expected data bytes).
The large value you see in Python
0x63080000000602
is a strong indication that the CAN message struct is being interpreted with the wrong layout. The lower bits (0x602) match CAN ID 602, while the upper bytes (0x63, 0x08) correspond to the first data byte and the DLC.

This is a typical LP64 vs. LLP64 / struct-packing mismatch in the Python layer, not an issue in libPCBUSB. I’ve documented this in my notes here (see “Remarks”):
https://gist.github.com/mac-can/a43f08e530714dd74689762f62f88dca

I don’t use or support python-can myself, so I can’t debug their backend, but you may find this useful:
I provide a minimal, working Python wrapper that matches the correct TPCANMsg layout (aligned with PEAK’s Python structure definitions):
https://github.com/mac-can/PCBUSB-Library/tree/main/Examples/Python

It can serve as a reference for how the struct must be defined on macOS.