Pgn ID and the key to the PgnLibrary hash map

[photex]

Howdy!

I was expecting to be able to fetch a message definition via it's declared message id in the dbc file. For example, I have BO_ 1156 GPS_01: 8 ECIGateway. The problem is that https://github.com/jmagnuson/canparse/blob/master/src/pgn.rs#L163 determines the key... and this derived key is the only way to access a message definition. Because message definitions get merged based on this derived key, I can't implement a reasonable lookup by name either. Signal definitions can be found, but this differs from my understanding of how things should or could be arranged.

Since I'm new to CANbus in general and don't have an entirely clear picture of all the various incarnations of it, I didn't want to submit a PR where I fixed this for myself but it was just radically broken for a more common use case. Perhaps my understanding in general is wildly incorrect, but I'm following along with guides such as this http://socialledge.com/sjsu/index.php/DBC_Format.

What's the principle at work here?

Thanks!

[jmagnuson]

I tried to name PgnLibrary as abstractly as possible without explicitly calling it a J1939Library, but that's really what it is. The Pgn prefix is just an artifact of the J1939 spec, but it should probably be renamed to avoid confusion. With that, it is necessary to know the J1939 message spec in order to know why that line exists-- https://www.kvaser.com/about-can/higher-layer-protocols/j1939-introduction/

Basically, message ID values like Priority and SourceAddress-- variables that would otherwise make the lookup table useless-- get stripped off by PgnLibrary and it's up to the consumer to do the likewise in order to get the correct definition. For example, one j1939.dbc I have calls out message definition EEC1 with ID 2364540158 (0x8CF004FE) while another calls it out as 2364539904 (0x8CF00400). Both are "correct" in the sense that the PF+PS (0xF004) values can be derived, but makes it difficult for the consumer to guess which one that a received CAN message might correspond to at runtime.

I think what needs to happen is to create a DbcLibrary that doesn't lose any information about the message definitions (but provides some useful API for lookups, conversion, etc.), and just derive the PgnLibrary based on that.

Thanks for the report!

[photex]

This makes perfect sense now. Thanks for the explanation!

[jmagnuson]

Hey @photex, I finally started to implement a generalized DbcLibrary that should hopefully work for your use-case. Check out #16 -- any feedback you have would help; I'm still working on a suitable API.