dbc paring, message._fmt with wrong padding

Hi, first cool project!

I think there is a bug in computing the padding for some messages:

I have a messgae format in DBC like this:

BO_ 1 MSG0: 8 E1
 SG_ A : 6|15@0+ (1,0) [0|32768] ""  E1
 SG_ B : 7|1@0+ (1,0) [0|1] ""  E1
 SG_ C : 38|15@0+ (1,0) [0|32768] ""  E1
 SG_ D : 39|1@0+ (1,0) [0|1] ""  E1

It results in a fmt string with more than 64 bit due to too large padding like this: p24u2u15p30u1u15

I don’t know the exact syntax of the DBC file, but the definition of start in not intuitive. The Vector DBC editor reports as startbits: D->39 C->40 B->7 A->8

I think the logic in this function of start + length may not be right. May be even the start bit coputed by your code before is wrong.

def _create_message_encode_decode_format(signals):
    fmt = ''
    end = 64
    for signal in signals:
        padding = end - (signal.start + [signal.length)

Let me know it this it the right way to report the issue, if you plan to fix it or would like to have more information.

[karlpeterhugo]

Hi, first simple test looks good. I plan to confirm and provide a test case on Monday.

[karlpeterhugo]

Hi, thank you for the quick response. I will report if it works tomorrow.

I made some changes on a branch https://github.com/eerimoq/cantools/commit/bd90c6052efb6600736ecc9526814582c13dff95 that gives 64 bits in the format string (p16u15u1p16u15u1), but I’m not sure it is correct. B is mapped to bit 0, and A to bit 1, which does not match your Vector output.

That might be quite right. The Vector Editor also shows a bit-layout that matches your format string (2 bytes are used, 2 unused, 2 used, 2 unused). I think its just Vectors is counting bits inside a byte the other way around, hence showing non intuitive values for their signal.start.

Am 10.08.2017 um 18:06 schrieb Erik Moqvist [e-mail]:

Hello,

this is the right place to file issues. I don’t know all details about the DBC format myself, and I’m happy no pointed out that there is a problem in the package.

The 0 after the @ is the byte order of the signal. Looks like big endian byte order format is incorrect indeed, the number of bits in the format should be max 64.

The problem is probably not in _create_message_encode_decode_format, but that the start bit in big endian signals should be converted somehow to the internal represenation of the frame data. I don’t quite understand how to perform this conversion, and I don’t have any good tools available as guidance, so it would be lovely if you can provide more information about the expected format string.

I made some changes on a branch https://github.com/eerimoq/cantools/commit/bd90c6052efb6600736ecc9526814582c13dff95 that gives 64 bits in the format string (u16u15u1u16u15u1), but I’m not sure it is correct. B is mapped to bit 0, and A to bit 1, which does not match your Vector output. Anyway, the problem you highlight in this issue should be fixed, we just have to figure out how.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/eerimoq/cantools/issues/5#issuecomment-321597281, or mute the thread https://github.com/notifications/unsubscribe-auth/Add8_dJwKO8ANdJSSGjmm1ywRY09y82mks5sWyprgaJpZM4OzXBA.