- Host Configuration
- Runtime Node Configuration
- SDF Configuration
- Managing the Runtime
- Logfile Management
- Application Development
- Dynamic Driver Development
- Ecosystem Tools
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,
- Translates the input DBC file to a comparable IDL file that defines the required data types to store incoming sensor data
pdm-gento 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
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.
Errors parsing the DBC file are printed to
pdm-gen specific errors report to the
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
*.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
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