Generate a DBC Based Driver

polysync-generate is able to generate a custom data model and compatible driver interface that is capable of parsing, processing, and publishing of each message and signal defined in the provided DBC file. The sensor data is available as custom PolySync Core message types that can be subscribed to by any PolySync node.

To support a new sensor, polysync-generate:

  • Translates the input DBC file to a comparable IDL file that defines the required data types to store incoming sensor data
  • Invokes pdm-gen to parse all IDL files to create a data model with the provided PolySync message types, and the sensor specific message types
  • Generates a driver interface to parse incoming CAN data and publish sensor-specific PolySync messages

Generate the data model and driver

DBC input file

The polysync-generate node requires an input DBC file defining the sensor’s data model and communication protocol.

The node supports all valid DBC file definitions. Naming collisions are handled by modifying message and signal names to be unique within the scope.

Generating the data model and driver interface

Provide the path to the DBC file to generate the data model and driver interface for the CAN based sensor.

$ cd <build-directory>/
$ polysync-generate driver dbc -f ./path/to/sensor.dbc

You can optionally provide a custom node name and output directory.

$ cd <build-directory>/
$ polysync-generate driver dbc -f ./path/to/sensor.dbc -o ./path/to/output/directory -n sensors_name

The data model and driver generation can take up to 15 minutes, depending on the number of CAN messages and signals defined in the DBC file.

Error reporting

Errors parsing the DBC file are printed to stdout, and pdm-gen specific errors report to the ./<output-directory>/pdm/error.log file.

Naming collisions like the one below are handled by modifying DBC message and signal names to be unique within the scope.

ERROR: DBC file not valid, duplicate signal name - CAN_TX_ROLLING_COUNT_3 in VECTOR__INDEPENDENT_SIG_MSG

Manually update the DBC file to follow the DBC file format and syntax.

Copy the data model files

The following files are generated, and must be copied to the system locations. The *.so library files must be copied to start PolySync nodes that use this data model, and the *.h and *.hpp header files must be copied to build nodes against the data model.

$ cd <build-directory>/<custom_node_name>/
$ cd pdm/
$ sudo cp *.so* /usr/lib/
$ sudo cp *.h* /usr/local/polysync/pdm/
	<file>					-> <system-location>
	pdm/libpolysync_data_model.so		-> /usr/lib/
	pdm/libpolysync_cpp_message_support.so	-> /usr/lib/
	pdm/psync.h				-> /usr/local/polysync/pdm/
	pdm/psyncDcps.h				-> /usr/local/polysync/pdm/
	pdm/psyncSacDcps.h			-> /usr/local/polysync/pdm/
	pdm/psyncSplDcps.h			-> /usr/local/polysync/pdm/
	pdm/PolySyncDataModel.hpp		-> /usr/local/polysync/pdm/

These files are generated, but do not need to be copied anywhere.

	psync.idl				-> used to generate libpolysync_data_model.so
	psyncSacDcps.c				-> symbols in libpolysync_data_model.so

Data model limitations

Build the driver

The driver interface code is generated and needs to be built. The build artifact is a shared object library that can be loaded by the Core dynamic driver.

Build the Hardware Abstraction Layer (HAL), then the PolySync Abstraction Layer (PAL).

$ cd <build-directory>/<custom_node_name>/
# build the HAL and PAL
$ cd hal/
$ make
$ cd ../pal/
$ make 

If errors are seen while building the HAL or PAL, ensure the data model files have been copied to the correct system locations.

The sensor interface is built, and ready to be loaded by the dynamic driver. Copy the interface to PSYNC_HOME/lib/ so it can be located by the dynamic driver.

$ cd <build-directory>/<custom_node_name>/
# copy the file to the system
$ sudo cp lib/<architecture>/<operating-system>/libps_<generated-node-name>_interface.so /usr/local/polysync/lib/

Start the driver

Define the node

Define the sensor node in the SDF with the Configurator.

The sensor node interface name in the Configurator will match the custom name provided to polysync-generate, or will default to myCustomNode.

Locate and configure the CAN channel, and update the SDF with the IO Configuration information.

Start the node

Access sensor data

With the driver running, sensor data is published to the Core bus as PolySync message types. Access the data by creating applications to subscribe to the message types output by the driver.

View the full list of message types output by the driver in the SDF Configurator. Each supported message type has a message publish toggle.

Locating message types with echo

Alternatively you can use the C++ polysync-echo example─while the Core dynamic driver is running─to print a list of all detected message types currently being published to the PolySync bus by all nodes.

$ polysync-echo -a

Note that you will need to clone, and build the echo example before it can be started. Instructions can be found in the example’s README.md file.