Startbit position > 255

[hakwes]

Hi!

I have a DBC file with a message with a "large" dlc and with a signal that has startbit 256

BO_ 200 SENSOR_SONARS: 39 SENSOR
 SG_ SENSOR_SONARS_no_filt_rear m1 : 256|6@1+ (0.1,0) [0|0] ""  DBG

This can not be loaded by the library.
Any plans of supporting this?

[Adhara3]

Hi,

this isn't very standard, is it?
Even CANdb++ (by Vector) complains about both the DLC and the start bit...
It would be very easy to support, the limit is just the Message.StartBit property that has type byte.
It really depends is @EFeru wants to supports non standard stuff.

A

[EFeru]

Is this CAN FD related? Because I would definitely like to support CAN FD, but need to look into it in more detail.

[hakwes]

Sorry for any confusion, I'm fairly new to CAN.
This is a J1939 DBC file which I guess is a bit different.

[taylorjdlee]

@EFeru Yes I found this issue as well. This is due to the J1939/21 transport layer protocol that has the ability to send more than 8 databytes per message through the use of multiple packets. Just looking at the signals column the highest bitpos value in my J1939 .dbc is 1584 (see attached)

This is because it's tied to the Ignitor Loop Information which is part of the J1939 standard with a CAN ID of 486349310 and a PGN of 64793. This specific CAN ID has 200 bytes of data i.e 25 CAN packets are sent to complete the message you can see the CAN ID in my database below

In theory if the bitpos is increased to a 16-bit unsigned short instead of an 8-bit unsigned byte it should be fine being able to read .j1939 dbc files. (see the errors thrown below)

Unhandled exception. System.OverflowException: Value was either too large or too small for an unsigned byte.
at System.Number.ThrowOverflowException(TypeCode type)
at System.Byte.Parse(String s, IFormatProvider provider)
at DbcParserLib.Parsers.SignalLineParser.AddSignal(String line, IDbcBuilder builder)
at DbcParserLib.Parsers.SignalLineParser.TryParse(String line, IDbcBuilder builder)
at DbcParserLib.Parser.ParseLine(String line, IDbcBuilder builder)
at DbcParserLib.Parser.ParseFromReader(TextReader reader)
at DbcParserLib.Parser.ParseFromStream(Stream dbcStream)
at DbcParserLib.Parser.ParseFromPath(String dbcPath)
at SqlTest.Main()

[taylorjdlee]

@EFeru @Adhara3 @hakwes I recommend checking out this link if you want to know more:
https://www.embitel.com/blog/embedded-blog/what-is-j193921-transport-protocol-learn-how-it-supports-more-than-8-bytes-data-over-can

[taylorjdlee]

I can confirm after making local changes from byte to ushort for the Message.Startbit variable. The code compiles without errors when reading my J1939 .dbc file. This was pretty much expected but thought to comment here to confirm the suggested changes do work.

[hakwes]

@taylorjdlee Thank you for the link and the explanation! So to support J1939 multiple packets, a new packer class would have to be implemented?

[EFeru]

Hi @taylojdlee, I will check and make the update for the next release. Thanks for all the input.

[myklory]

I have the same question, in J1939.dbc, there are many message length large than 255 bit, like ILI message. I can fix it in the local version, but I still hope the nuget version can support J1939.dbc.
the attached file is J1939.dbc, you can Unzip it and test.
Best Regard.
j1939dbc.zip

[EFeru]

Should be fixed by #11 .Thanks @hakwes !