I use "ford_cgea1_2_bodycan_2011.dbc" for testing CDS, it succesfuly parses (actually it is the reason I am using it, from this issue). I was trying to send signal using CanSignalSender, but cansignalencoder gave the following error.

[cds] [error] [signalToRaw():cansignalencoder_p.cpp@104] Factor for HvacEvap_Te_Offst signal is 0! Singal encoding failed.

I tracked error a little bit and found out that factor of can message is parsed incorrectly as 0. Then checked other messages and found that all factors are parsed as integers (by observing CanSignalData block) and they are floor'ed. Table can be seen in the figure below.

The message I am playing is the one with id 0x326 and it is given below.

BO_ 806 Compressor_Req: 8 XXX
SG_ HvacEvap_Te_Rq : 33|10@0+ (0.125,-50.0) [0|0] "Degrees C" XXX
SG_ HvacEvap_Te_Actl : 17|10@0+ (0.125,-50.0) [0|0] "Degrees C" XXX
SG_ HvacAirCond_B_Rq : 7|1@0+ (1,0) [0|0] "" XXX
SG_ HvacEvap_Te_Offst : 1|10@0+ (0.125,-50.0) [0|0] "Degrees C" XXX

If dbc file has windows line ending parser fails.
Example: https://github.com/commaai/opendbc/blob/master/tesla_can.dbc#L101

This is a part of #16

Travis build fails, (as you have probably seen).

I looked into it since I wanted it fixed. Summarizing (but you might know all this already):

• CMakeLists in CANdb build uses the module named GoogleTest, which is not found so the travis build fails.
• GoogleTest module was introduced in cmake 3.9
• The Docker image that is used, bartekt/can_dev_base_image, has cmake version 3.8.2
• The current standard Travis image actually has 3.9.2 which should be enough. I therefore tried the build without the docker image but then the latest gcc-6 was missing, so I stopped there.

In summary, either update cmake version in the container, or find another way to install gcc so that the travis-provided image can be used?
(By the way, it's not terribly efficient now to pull the 1GB+ build container for every build (it's not cached but pulled every time I believe?))

• I could not do the first option for you and send a PR because I don't know where the Dockerfile is at (not at https://github.com/bartekt from what I could see?, and also not in this (CANdb) repository)

If you can't update the base image or find an appropriate backport there's also this option by installing compiled cmake versions from cmake site, for example the shell installer can be convenient:

wget https://cmake.org/files/v3.11/cmake-3.11.2-Linux-x86_64.sh
sudo bash cmake-3.11.2-Linux-x86_64.sh --prefix=/usr/local --exclude-subdir

Hello,

in this file CANdb/src/dbcparser.cpp at line192:

    pegParser["val_entry"] = [&can_db, &phrasesPairs](const peg::SemanticValues&) {
        std::vector<CANdb_t::ValTable::ValTableEntry> tab;
        std::transform(phrasesPairs.begin(), phrasesPairs.end(), std::back_inserter(tab), [](const auto& p) {
            return CANdb_t::ValTable::ValTableEntry{ p.first, p.second };
        });
        can_db.val_tables.push_back(CANdb_t::ValTable{ "", tab });
        phrasesPairs.clear();
    };

the signal id/name is not parsed from the DBC file "VAL_TABLE_" and "VAL_" section, but just an empty string ("") is used.

It should be placed in the "identifier" member of "ValTable" struct.

Would it be possible to fix this upstream or provide us just a suggestion on how to do it?
Thanks for your support,
enrico

I am using CANdb in multiple small projects by now, usually linked statically (to executables and shared plugins) to reduce build times and to guarantee build stability/ code compatibility over time. By now, I am maintaining my own fork which I adapt for my specific needs to accommodate for this. I understand you are pursuing a more "rolling" release of your software collection. However, I was wondering if you were interested in any of the following from here: https://github.com/jenszo/CANdb/tree/simple_library_api

• "DBCSimpleParser" - my wrapper with d-pointer to hide std::expected from linking target and reducing potential binary conflicts in case std::expected changes and/or user code ships it's own variant (CanDbOrError is part of your API).
• -fPIC compilation to allow static linkage to shared plugins in the first place
• Pinning specific versions of the dependencies (cxxopts, spdlog, etc.) Particularly spdlog is critical as the current implementation requires user-code to implement a kDefaultLogger (which is marked extern in the static library) and this may again lead to a broken ABI.
• shipping a *.cmake file for CANdb for cmake to be able to search for it and import a library target.

This all should not undervalue your work - and I love the way this parser is implemented.
Any thoughts on this?

Hello,

we would like understand more about parsing performances of CANdb, and where cpu-time is actually spent when parsing a DBC.

In our application we are loading 2 DBC files:

• CAN1.dbc loaded in = 925[ms] -> which on ARM embedded system is almost 15[secs]
• CAN2.dbc loaded in = 1473[ms] -> which on ARM embedded system is almost 20[secs]

here is the perf flamegraph of the first 40seconds of the whole applications startup.

We have many modules in the application, however DBC parsing, in particular peglib.h codepath, covers almost 50% of all startup cpu-time.

We tried to switch the peglib submodule to the master branch, and made some quick adjustments to compile with std::string_view support. However the CANdb parsing is entering an infinite loop...we are investigating further.

Do you think that, for improving the parsing performance on an iMX6 embedded system, this is the way to go?

thanks for your support

I found a "bug" in the parsing of numbers. As of now the parsing is handled by the following line:

SG_ HVB_tCellMean : 23|16@0+ (0.01,-273.15) [-40|105] "degC" Charger,VCU

It will parse factor=0 instead of 0.04 and offset=-273 instead of -273.15

I changed my environment variable when using CANdb to en_US-UTF.8 and now it works.

I think the solution is to define the parsing locale in the libary itself or better: change the conversion function to not use locale at all.