PCAN-Basic: Configuring Channel Bit Rate Dynamically

Overview: Who Owns the Bit Rate in a PCAN Application

A recurring integration problem on multi-channel PEAK-System CAN interfaces: an application must bring up six channels, each connected to a different CAN device family running a different bit rate, and the bit rates must be selected automatically at connection time. Engineers frequently reach for the PCAN Nets Configuration tool (shipped with PCAN-Explorer) to pre-define the nets, then wonder why the configured bit rate does not appear to take effect, or why it cannot be changed on the fly.

The core rule is this: the tool you use to define the bit rate must match the API your application links against. Mixing a PCAN-Developer-oriented configuration tool with a PCAN-Basic application produces the confusion described above.

Why PCAN Nets Configuration Appears to Do Nothing

Two separate behaviors combine to create the symptom:

1. Configuring a net does not initialize hardware. Creating an entry in PCAN Nets Configuration only stores a definition. The CAN controller is not touched, no bit timing registers are written, and no bus activity occurs.
2. Hardware initialization happens on first client attach. The interface is initialized with the configured bit rate only when the first application actually opens one of those configured nets — and only through the API that understands nets (the PCAN-Developer API).

A PCAN-Basic application never opens a named net. It opens a channel handle directly and supplies its own bit rate. Therefore the value stored in PCAN Nets Configuration is bypassed entirely, and the bit rate the bus actually runs at is the one your code passed in.

Decision Path: Which Approach Fits Your Requirement

Requirement: six channels, each auto-configured to the correct bit rate depending on which CAN device is connected.

Because the described toolchain is PCAN-Basic plus the Explorer-supplied configuration utility, the practical answer is the first row: remove PCAN Nets Configuration from the workflow and set the bit rate in code. No additional licence is required for that.

Runtime Bit Rate Change Procedure (PCAN-Basic)

The PCAN-Basic API has no "set bit rate" function on an already-open channel. Bit timing is latched at initialization. The supported sequence is therefore a close/re-open cycle per channel.

1. Stop the application's read loop for that channel and flush any pending TX queue entries. Do not let another thread call read/write during the transition.
2. Release the channel with the uninitialize call (CAN_Uninitialize) for the specific channel handle, not the "all channels" wildcard, so the other five channels keep running.
3. Re-initialize the same channel handle with the new bit rate constant via CAN_Initialize(Channel, Btr0Btr1). For CAN FD-capable channels the FD variant of the initialize call takes a bit-rate string instead of the classic BTR0/BTR1 word.
4. Check the return status. Any non-OK result must be decoded to text before it is logged — PCAN-Basic provides an error-text lookup call for this. Do not proceed to read/write on a failed handle.
5. Reset the receive queue and error state before resuming traffic, so stale frames captured at the old bit rate are not delivered to the application.
6. Restart the read loop.

Reference structure for a six-channel auto-configuration loop

// Pseudocode - map each channel to the device type expected on it
for ch in [CH1..CH6]:
    desired = LookupBitRate(DeviceTypeOn(ch))   // from your config file
    if CurrentBitRate[ch] != desired:
        StopReadThread(ch)
        CAN_Uninitialize(ch)
        st = CAN_Initialize(ch, desired)
        if st != OK:
            log(CAN_GetErrorText(st))
            continue
        ResetQueues(ch)
        CurrentBitRate[ch] = desired
        StartReadThread(ch)

Auto-Detecting the Correct Bit Rate

If the connected device type is not known in advance, the bit rate must be probed. PCAN-Basic supports a listen-only mode, which is the safe way to do this: the controller does not send acknowledge bits, so a wrong-bit-rate attempt cannot corrupt an active bus with error frames.

1. Build an ordered candidate list of bit rates (put the most likely device rates first to shorten detection time).
2. Initialize the channel at candidate rate n.
3. Enable listen-only before allowing any transmission on the channel.
4. Read for a fixed dwell window (long enough to span the slowest expected cyclic message on that device).
5. Match criterion: valid frames received and the bus/error status stays clean. Bus-heavy error counters or a bus-off/warning status indicate a bit rate mismatch.
6. On mismatch, uninitialize and repeat with candidate n+1. On match, uninitialize, then re-initialize normally (listen-only disabled) so the node can acknowledge and transmit.

Verification Checklist

Design Notes for Multi-Channel Deployments

• Keep bit rate assignment in an external configuration file (channel index → device type → bit rate), not in compiled constants. Field devices get swapped; recompiles should not be required.
• Do not run PCAN-Explorer against a channel while the application is initializing it at a different bit rate. The first client to initialize the hardware sets the timing, and a second client requesting different timing will be rejected or will get the existing rate.
• Serialize re-initialization: change one channel at a time and keep a per-channel state machine (Closed → Probing → Open). Concurrent uninitialize/initialize calls across threads are the usual source of intermittent initialization failures.
• If you later need multiple applications to share a single named net at a centrally managed bit rate, that is a PCAN-Developer capability, not a PCAN-Basic one. Plan the licence accordingly rather than trying to bend the Nets Configuration tool.

FAQ