Drivers
An overview of the drivers shipped with QInsight. Configuration parameters
are entered in the Settings field in the key=value;key=value form
(keys are case-insensitive). A driver handles the physical data transport —
interpreting the data is the job of a protocol.
When you add a driver, the Settings field is automatically pre-filled
with a template of all parameters (the Pre-filled line under each driver
below). These are only defaults — always overwrite them to match your real
setup. The Default column in the tables applies when you omit the
parameter entirely. Device-specific parameters (port, deviceId, ip)
must always be set by hand.
About settings parsing in general: keys are case-insensitive and values
may be quoted (port="COM3"). An unknown key (a typo or a name from an
earlier version) is ignored and the driver reports it with a warning in
the log, listing every key it does know; an invalid value falls back to
the default with a warning. Check the log after every settings change.
Reconnection
Every driver that talks to a device (Serial Port, TCP Client, TCP Server, PEAK CAN) behaves the same way after losing its connection and is configured with the same pair of parameters:
| Parameter | Default | Meaning |
|---|---|---|
reconnectDelayMs | 1000 (Serial Port 2000) | pause between two reconnect attempts in ms |
reconnectAttempts | -1 | how many times to retry after a failed attempt: -1 = forever, 0 = never (the driver stops at the first failure), N = give up after N consecutive failed attempts |
- The failure counter restarts after every successful connection — a long measurement survives scattered outages; only an unbroken run of failures exhausts the limit.
- During an outage the driver is Faulted, its protocols stay running and wait (XCP drops its session and re-establishes it when the transport is back, the Modbus master pauses polling). Once the connection is back the communication continues without any operator action.
- Every attempt is a warning in the log:
… failed (attempt 3/4): … Reconnecting in 1000 ms.With endless retries only the first three attempts are logged, then one line per minute with the current attempt number, so the log is not flooded. - When the limit is exhausted the driver logs an error
gave up after N reconnect attempt(s): …, stops its protocols and ends Stopped with that message. The other drivers and the runtime keep running; the stopped driver can be started again with the Start button in its properties — see Driver states and the Start button.
The TCP drivers have one more parameter, keepAliveMs (default 5000,
0 = off): after that much silence on the connection the operating
system sends keepalive probes (every second, the connection is closed
after three unanswered probes). A pulled cable or a vanished peer is thus
detected within seconds instead of the tens of seconds of the plain TCP
timeout. Switch it off only on networks where keepalive probes are
unwanted.
TCP Client
Technical name (stored in the project): TcpClientDriver
A bidirectional TCP client: connects to a server (device) and transports raw bytes. Framing and encoding are the protocol's job — typically JSON Signal Stream, Modbus Master (TCP), or XCP on TCP.
Pre-filled: ip=127.0.0.1;port=5000;connectionTimeoutMs=5000;reconnectDelayMs=1000;reconnectAttempts=-1;keepAliveMs=5000
| Parameter | Default | Meaning |
|---|---|---|
ip | 127.0.0.1 | server address |
port | 5000 | TCP port |
connectionTimeoutMs | 5000 | how long to wait for the connection to be established, in ms |
reconnectDelayMs | 1000 | pause between reconnect attempts, see Reconnection |
reconnectAttempts | -1 | number of reconnect attempts, -1 = forever |
keepAliveMs | 5000 | TCP keepalive: probes the connection after that much silence, 0 = off |
A quiet line is never treated as a fault (Modbus TCP sends nothing between
polls); a dead connection is detected by the keepalive. Timeouts below
1 ms are raised to 1. The former names reconnectTimeMs,
numberOfReconnections and idleTimeoutMs are no longer read — the log
shows an unknown-key warning and the settings have to be rewritten.
TCP Server
Technical name (stored in the project): TcpServerDriver
A binary TCP server (listener) transporting raw bytes — typically for Modbus Slave (TCP). Accepts one client; a new incoming connection replaces the current one.
Pre-filled: bindAddress=0.0.0.0;port=502;reconnectDelayMs=1000;reconnectAttempts=-1;keepAliveMs=5000
| Parameter | Default | Meaning |
|---|---|---|
bindAddress | 0.0.0.0 | local address the server listens on |
port | 502 | TCP port (the default matches Modbus TCP) |
reconnectDelayMs | 1000 | pause between attempts to open the port, see Reconnection |
reconnectAttempts | -1 | number of attempts to open the port, -1 = forever |
keepAliveMs | 5000 | TCP keepalive on the accepted connection, 0 = off |
bindAddress must be an IP address (0.0.0.0 = all interfaces,
127.0.0.1 = local machine only) — a host name is not accepted. For the
server the reconnection parameters apply to opening the listening
port: when the port is in use (another program already listens on 502)
or the given address does not exist in the system yet, the driver keeps
trying and comes up as soon as the port is free. A client going away is
not a fault — the server keeps listening and the next client takes over;
a clean disconnect is logged as client … disconnected, a connection
ended by the keepalive (cable pulled at the client) as the warning
client … lost.
Firewall: incoming connections to the server port must be allowed by the firewall on the PC running QInsight (Windows Defender Firewall or the firewall of an antivirus suite). In the rule the local side is the QInsight PC and the remote side is the master; after an outage the connection is always re-established by the master (the client).
Serial Port (COM)
Technical name (stored in the project): SerialPortDriver
A serial COM port transporting raw bytes — typically for Modbus RTU. One instance = one COM port; after a failure (e.g. a USB converter unplug) the port is reopened automatically.
Pre-filled: port=COM1;baudRate=9600;dataBits=8;parity=none;stopBits=1;handshake=none;reconnectDelayMs=2000;reconnectAttempts=-1
| Parameter | Default | Meaning |
|---|---|---|
port | — (mandatory) | COM port name, e.g. COM3 |
baudRate | 9600 | communication speed |
dataBits | 8 | number of data bits |
parity | none | parity: none, even, odd, mark, space |
stopBits | 1 | stop bits: 1, 1.5, 2 |
handshake | none | flow control: none, rts, xonxoff, rtsxonxoff |
reconnectDelayMs | 2000 | delay before reopening the port after a failure, see Reconnection |
reconnectAttempts | -1 | number of attempts to reopen the port, -1 = forever |
Type the parity/stopBits/handshake values exactly as listed — an
invalid value is replaced by the default with a warning in the log, and
the communication then runs with the wrong framing (typically 8N1 instead
of 8E1). baudRate and dataBits are passed to the port unchecked:
a nonsensical value (e.g. dataBits=9; the usual range is 5–8) fails when
the port opens and the driver retries every reconnectDelayMs — the cause
is in the log. Unplugging the USB converter is noticed by Windows at once;
a broken wire between two converters is not seen by the driver, only the
protocol reports it through its response timeout.
PEAK CAN Adapter
Technical name (stored in the project): PeakCANDriver
CAN bus access through a PEAK PCAN USB adapter; hands CAN frames to the protocols (Raw CAN Frames, XCP on CAN). One driver instance corresponds to one physical adapter — it is selected by the Device ID stored in the adapter, so the configuration survives plugging the adapter into a different USB port.
Pre-filled: deviceId=0x51;bitrate=250000;reconnectDelayMs=1000;reconnectAttempts=-1
| Parameter | Default | Meaning |
|---|---|---|
deviceId | 0 | adapter ID, always hexadecimal (range 0–FF per PEAK Settings); accepted forms 1A, 0x1A, 1Ah |
bitrate | 250000 | bus speed in bit/s, decimal: 50000, 100000, 125000, 250000, 500000, 800000, 1000000; any other value falls back to 250000 with a warning |
reconnectDelayMs | 1000 | pause between attempts to initialize the adapter, see Reconnection |
reconnectAttempts | -1 | number of attempts, -1 = forever |
The driver scans USB adapters (PCAN-USB 1–16). When no adapter with the given Device ID is found, or when two adapters share the same ID, the connection attempt fails with the cause in the log and the driver repeats it according to the reconnection parameters. An adapter unplugged while running (or a bus-off) is detected within a second: the driver releases the channel, tells the protocols the transport is gone and looks for the adapter again; after it is plugged back in, XCP re-establishes its session on its own.
Simulation
Technical name (stored in the project): SimulDataDriver
A testing driver — it only starts and stops the Simulation Signals protocol, which generates the simulated values itself in the periods of the events assigned to the variables. Lets you try out a project without hardware.
The driver has no settings. Older projects may still carry periodes=…
in the settings — the value is ignored; the simulation rate is driven
solely by the variables' events.
Virtual Variables Host
Technical name (stored in the project): VirtualDataDriver
Host of virtual variables — variables whose values are computed by Python scripts. The driver communicates with nothing: it only starts and stops the Virtual Variables protocol, which publishes the script writes as signal samples. What virtual variables are for and how they are configured is described under Virtual Variables; a complete walk-through is the example Simulation: all signals.
The driver has no settings.
Data Log Recorder
Technical name (stored in the project): FileDataLoggerDriver
Writes the values of selected variables into a binary .qilog file;
the logged variables are handed to it by the Data Log Pass-Through
protocol (PassThroughProtocol), which is added to the driver
automatically. Complete description including all parameters:
Logging data.
Data Log Replay
Technical name (stored in the project): FileDataReplayDriver
Replays a recorded .qilog file back into the variables. It is added to
the project by the Import button in the Runtime ribbon; its parameters
(file, mode, speed, loop) are described in
Replaying a log.
Drivers are plugins — for a custom driver see Custom extensions.