When parsing DBC, make sure there are no unused VAL_ and SIG_VALTYPE_ entries

[SebKuzminsky]

This makes DBC parsing a little more strict, rejecting DBCs with some common(?) errors.

[coveralls]

Pull Request Test Coverage Report for Build 8840594508

Details

• 14 of 20 (70.0%) changed or added relevant lines in 1 file are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage decreased (-0.06%) to 93.489%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/cantools/database/can/formats/dbc.py	14	20	70.0%

Files with Coverage Reduction	New Missed Lines	%
src/cantools/database/can/formats/dbc.py	1	96.7%

Totals
Change from base Build 8024886298:	-0.06%
Covered Lines:	7266
Relevant Lines:	7772

---

💛 - Coveralls

[SebKuzminsky]

@andlaus do you want me to rebase this on top of master to pick up the linter fix that you just merged?

[zariiii9003]

I'm not sure about this. I do not see the benefit of raising an exception on unused values. If CANdb++ can open these files, then they are valid and we should accept them.

[andlaus]

@andlaus do you want me to rebase this on top of master to pick up the linter fix that you just merged?

that would probably a good idea...

[SebKuzminsky]

I'm not sure about this. I do not see the benefit of raising an exception on unused values. If CANdb++ can open these files, then they are valid and we should accept them.

CANDB++ fails to open these files (and prints a very unhelpful error message). Current cantools (39.4.5) accepts these bogus/questionable files. This PR brings cantools into closer alignment with the CANDB++ parser.

[SebKuzminsky]

(Oops, didn't mean to close this PR!)

[SebKuzminsky]

And this latest force-push should fix the ruff linter error i introduced. 🙄

Sorry for all the churn...

[SebKuzminsky]

Here are some small DBC files that demonstrate the issue. They both define two packets with one signal each. In bad.dbc the VAL_ and SIG_VALTYPE_ lines have incorrect frame ids (COB IDs?) so they don't get applied to the signals. In good.dbc the frame ids have been fixed so the lines do get applied to the signals.

good.dbc.txt
bad.dbc.txt

The diff from bad to good is this:

$ diff -u bad.dbc good.dbc 
--- bad.dbc     2024-05-03 15:10:47.601981628 -0600
+++ good.dbc    2024-05-03 15:10:53.985999971 -0600
@@ -42,6 +42,6 @@
  SG_ signal2 : 0|32@1- (1,0) [0|0] "" Vector__XXX
 
 
-VAL_ 99 signal1 3 "High" 2 "Standard" 1 "Low" 0 "Unknown" ;
+VAL_ 1 signal1 3 "High" 2 "Standard" 1 "Low" 0 "Unknown" ;
 
-SIG_VALTYPE_ 345 signal2 : 1;
+SIG_VALTYPE_ 2 signal2 : 1;

Here is CANdb++ trying to load bad.dbc:

Here is cantools accepting bad.dbc and just ignoring the invalid VAL_ and SIG_VALTYPE_ lines, so the signals are interpreted as "default" integers:

$ python3 -m cantools list --all bad.dbc 
msg1:
  Frame ID: 0x1 (1)
  Size: 1 bytes
  Is extended frame: False
  Is CAN-FD frame: False
  Signal tree:

    -- {root}
       +-- signal1

  Signal details:
    signal1:
      Internal type: Integer
      Start bit: 0
      Length: 8 bits
      Byte order: little_endian
      Is signed: False
msg2:
  Frame ID: 0x2 (2)
  Size: 4 bytes
  Is extended frame: False
  Is CAN-FD frame: False
  Signal tree:

    -- {root}
       +-- signal2

  Signal details:
    signal2:
      Internal type: Integer
      Start bit: 0
      Length: 32 bits
      Byte order: little_endian
      Is signed: True

Here is CANdb++ successfully loading good.dbc:

And for completeness, here is cantools parsing good.dbc:

$ python3 -m cantools list --all good.dbc 
msg1:
  Frame ID: 0x1 (1)
  Size: 1 bytes
  Is extended frame: False
  Is CAN-FD frame: False
  Signal tree:

    -- {root}
       +-- signal1

  Signal details:
    signal1:
      Internal type: Integer
      Start bit: 0
      Length: 8 bits
      Byte order: little_endian
      Is signed: False
      Named values:
        3: High
        2: Standard
        1: Low
        0: Unknown
msg2:
  Frame ID: 0x2 (2)
  Size: 4 bytes
  Is extended frame: False
  Is CAN-FD frame: False
  Signal tree:

    -- {root}
       +-- signal2

  Signal details:
    signal2:
      Internal type: Float
      Start bit: 0
      Length: 32 bits
      Byte order: little_endian
      Is signed: True