Hi,
I’d like to raise a question about how DbcParser should handle duplicate signal names within the same message, but appearing under different multiplex identifiers.
I have a real‑world DBC where a message contains two SG_ entries with the same signal name, but each belongs to a different multiplexing branch. For example:
SG_ MySignal m0 : 0|16@1+ (1,0) [0|100] "" Vector__XXX
SG_ MySignal m1 : 0|16@1+ (1,0) [0|100] "" Vector__XXX
Vector’s CANdb++ loads this DBC without errors, and the behavior seems intentional — some OEM databases also use identical names in mutually exclusive multiplex branches.
However, DbcParser currently treats this as a duplicate definition and rejects it, which is also reasonable:
The official Vector DBC format documentation never explicitly states that multiplexing introduces a separate namespace, nor does it formally endorse duplicates. The grammar defines a message’s signal list as a flat structure, leaving the interpretation somewhat ambiguous.
Given this ambiguity, I’m not sure whether supporting these duplicates is the right choice for DbcParser, or whether enforcing uniqueness is preferable for consistency and error‑detection.
Request / Discussion point:
Would it make sense to consider supporting (or at least optionally allowing) identical signal names across different multiplex branches, matching CANdb++ behavior?
Or does the project prefer to enforce strict uniqueness for clarity and maintainability?
I’m happy to provide a minimal DBC reproducer if useful.
Thanks for considering this—looking forward to hearing your perspective.
Hi,
I’d like to raise a question about how DbcParser should handle duplicate signal names within the same message, but appearing under different multiplex identifiers.
I have a real‑world DBC where a message contains two SG_ entries with the same signal name, but each belongs to a different multiplexing branch. For example:
Vector’s CANdb++ loads this DBC without errors, and the behavior seems intentional — some OEM databases also use identical names in mutually exclusive multiplex branches.
However, DbcParser currently treats this as a duplicate definition and rejects it, which is also reasonable:
The official Vector DBC format documentation never explicitly states that multiplexing introduces a separate namespace, nor does it formally endorse duplicates. The grammar defines a message’s signal list as a flat structure, leaving the interpretation somewhat ambiguous.
Given this ambiguity, I’m not sure whether supporting these duplicates is the right choice for DbcParser, or whether enforcing uniqueness is preferable for consistency and error‑detection.
Request / Discussion point:
Would it make sense to consider supporting (or at least optionally allowing) identical signal names across different multiplex branches, matching CANdb++ behavior?
Or does the project prefer to enforce strict uniqueness for clarity and maintainability?
I’m happy to provide a minimal DBC reproducer if useful.
Thanks for considering this—looking forward to hearing your perspective.