Link a driver and a protocol

The communication path in a project always has the shape driver → protocol → variable:

• the driver handles the physical data transport,
• the protocol (one or more under a single driver) decodes the data,
• the variables assigned to the protocol receive the resulting values.

One driver can contain multiple protocols — e.g. several different sets of messages can be decoded on a single CAN bus at the same time.

The driver and the protocol must understand each other

Each driver hands data to its protocols in a certain form: the TCP Client, TCP Server, and Serial Port pass raw bytes, PEAK CAN passes CAN frames. The protocol must be built for the same kind of data — assign a byte protocol (JSON Signal, Modbus, XCP on TCP) to a byte driver and a CAN protocol (Raw CAN, XCP on CAN) to a CAN driver.

Project Configuration guards this for you: after you select a driver, protocols that cannot work with it are greyed out in the protocol list. Hovering a greyed-out protocol shows a tooltip explaining what it needs — e.g. "requires a driver providing CAN frames". Some protocols are designed for one specific driver (e.g. Virtual Variables for the Virtual Variables Host) and only stay selectable under that driver.

Common pairs:

Parameters of all protocols are in the reference.

Check

After adding, make sure both the driver and the protocol have Enabled checked and the driver has its Settings filled in correctly. The whole path is first exercised when the communication starts (Runtime → Connect) — status and errors appear in the Logs window.

Next

The communication path is ready — time to put data on it: Variables.