Unfortunately in my bachelor thesis i have to read in also the value tables of a dbc file. The comand line feedback says that this is deprecated. Is there a possibility to reactivate this functionality?
Thanks a lot for your support, Johannes
Last edit: Johannes Junker 2018-09-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The parser reads the value table definition in the DBC file but doesn't
store the found information in the data model. Consequently, this
information can't be used in the generated text output.
The reasons for this decision: The format specification of DBC designates
the value tables and related structures as "aren't used" or "normally not
used". Moreover, the semantics of these elements is not explained and
remains unclear. Learning from practice is indeed impossible because of
the "normally not used".
It's obvious that value tables are a kind of enumerations for signal
values, but there's no explanation given how they should be used. There's
a direct link from "signal type" definitions to value tables and there are
"signal type refs", which connect particular signals with signal types
(and thus with value tables), but all of this is redundant with the
normally used mechanism of implicitly specifying the signal type
information in the only appearance of a signal in a message plus having a
"value description for signal" for the affected signals. All real existing
DBC files use the keyword VAL_ ("value description for signal") to define
the required value enumeration for a particular signal.
I've occasionally seen DBC files still having value tables but the
information therein was not used, not connected to signals and the signals
still had their individual value descriptions, so that the value tables
were effectively useless. So I wonder, what kind of DBC you have and why
you need to evaluate this? Can you share this with me?
On the Java programming level it is quite easy and straight forward to
extend the parser so that it puts the missing information into the data
model from where a template could access it. However, this would require
setting up the complete build tool chain with Java, ANT and SVN and you
would need to understand the ANTLR concepts, its grammar and the
interrelation with the listener.
I'm not going to do this as long as I don't have a clear and unambiguous
explanation of the semantics of the value tables and the related syntax
elements. Otherwise I would make the mistake of offering some information
without being able to say/document what it is for or what to do with it.
P.S. A discussion in German would be possible through
mailto:Peter_Vranken@Yahoo.de
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Because of the described problems i consider to implement the value table (its actually just one) in my programm without reading it out of the DBC file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Amazing project!
Unfortunately in my bachelor thesis i have to read in also the value tables of a dbc file. The comand line feedback says that this is deprecated. Is there a possibility to reactivate this functionality?
Thanks a lot for your support, Johannes
Last edit: Johannes Junker 2018-09-06
The parser reads the value table definition in the DBC file but doesn't
store the found information in the data model. Consequently, this
information can't be used in the generated text output.
The reasons for this decision: The format specification of DBC designates
the value tables and related structures as "aren't used" or "normally not
used". Moreover, the semantics of these elements is not explained and
remains unclear. Learning from practice is indeed impossible because of
the "normally not used".
It's obvious that value tables are a kind of enumerations for signal
values, but there's no explanation given how they should be used. There's
a direct link from "signal type" definitions to value tables and there are
"signal type refs", which connect particular signals with signal types
(and thus with value tables), but all of this is redundant with the
normally used mechanism of implicitly specifying the signal type
information in the only appearance of a signal in a message plus having a
"value description for signal" for the affected signals. All real existing
DBC files use the keyword VAL_ ("value description for signal") to define
the required value enumeration for a particular signal.
I've occasionally seen DBC files still having value tables but the
information therein was not used, not connected to signals and the signals
still had their individual value descriptions, so that the value tables
were effectively useless. So I wonder, what kind of DBC you have and why
you need to evaluate this? Can you share this with me?
On the Java programming level it is quite easy and straight forward to
extend the parser so that it puts the missing information into the data
model from where a template could access it. However, this would require
setting up the complete build tool chain with Java, ANT and SVN and you
would need to understand the ANTLR concepts, its grammar and the
interrelation with the listener.
I'm not going to do this as long as I don't have a clear and unambiguous
explanation of the semantics of the value tables and the related syntax
elements. Otherwise I would make the mistake of offering some information
without being able to say/document what it is for or what to do with it.
P.S. A discussion in German would be possible through
mailto:Peter_Vranken@Yahoo.de
Thanks for the detailed answer.
Because of the described problems i consider to implement the value table (its actually just one) in my programm without reading it out of the DBC file.