PCAN-USB can report a frame to the transmitting application and PCAN-View without that frame reaching either of the other CAN interfaces. Follow the packet: application, PCAN-Basic call, driver queue, USB interface, CAN controller, transceiver, cable, and receiving nodes. A local transmit indication proves progress through part of that path; reception at an independent interface proves delivery on the physical bus.
Where does the frame stop?
Start with simultaneous observations from the transmitting PCAN-USB and an independent CAN interface. In the reported setup, both a Vector interface and a second PCAN interface failed to receive the affected frames, while PCAN-View on the transmitting hardware displayed them. That isolates the failure to the transmitting path or its connection to the bus rather than to one receiver.
| Observation | Meaning | Next check |
|---|---|---|
| Frame appears locally and on either independent interface | The controller placed the frame on the bus; investigate receiver filtering, decoding, or application handling. | Compare identifier format, filters, and receive timestamps. |
| Frame appears locally but on neither independent interface | The API or driver accepted the request, but physical delivery and acknowledgment are unproven. | Check wiring, node power, controller status, and bus-off state. |
| Frame appears nowhere | The request may not have reached the driver or may have failed immediately. | Record the transmit-call return status and channel state. |
Do not use PCAN-View on the same hardware as the sole wire-level witness. Its displayed transmit record can originate from the local software and device path. Capture from an electrically separate interface connected to the same CAN conductors.
Is the physical CAN bus able to acknowledge traffic?
Layer one first. CAN requires another active node to acknowledge a valid data frame. Device restarts can remove receivers temporarily; a disconnected cable, loss of node power, or a short circuit can also prevent acknowledgment. The transmitting controller then retries and accumulates transmit errors. CAN error confinement can eventually move it to bus-off, where it stops participating in normal traffic.
| Reading | Pass condition | Failure branch |
|---|---|---|
| Bus wiring and connector seating | Continuous connection between the transmitter and independent monitors | Repair the physical path before resetting the controller. |
| Node power during restart | At least one correctly configured active node can receive and acknowledge | Delay transmission or coordinate restart sequencing. |
| Configured CAN bitrate and format | All active nodes use the same bus timing and frame format | Correct configuration, then retest from an idle bus. |
| Controller status after the event | Channel remains bus-on without an active bus-off indication | Use the reset decision described below. |
A reset cannot correct an open circuit, missing power, incorrect bus timing, or a short. Automatic recovery against a persistent physical fault merely repeats the bus-off and recovery cycle. Monitor the controller status while correcting the underlying layer-one condition.
Did the transmit request reach a blocked outgoing path?
Record each transmit call's return value and timestamp, then correlate it with the two independent captures. A successful software call means the request passed the API boundary; it does not mean the CAN controller completed arbitration, received an ACK, or finished transmission.
A pending frame can remain in the physical outgoing path when the network disappears before transmission and acknowledgment complete. This explains the key symptom: the application and local viewer can show the frame as sent while neither independent interface sees a valid frame on the bus. Once the controller is bus-off or its outgoing state is stalled, additional application activity may continue to create local indications without restoring physical communication.
| Path element | Reading to take | Decision |
|---|---|---|
| Application | Transmit-call status and timestamp | If rejected, correct initialization or API handling before testing the bus. |
| Driver/device queue | Behavior before and after CAN_Reset
|
If queue reset alone clears the symptom, retained queued traffic was involved. |
| CAN controller | Bus-off status | If bus-off is active, select automatic recovery or a controlled hardware reset. |
| Physical bus | Independent capture and ACK-capable node availability | If no independent receiver sees traffic, continue below the local display layer. |
Will a queue reset or hardware reset recover the channel?
By default, CAN_Reset—called Reset by the class methods—empties the PCAN channel's transmit and receive queues. With PCAN_HARD_RESET_STATUS active, the same reset call additionally performs a hardware reset. That distinction matters when clearing software queues does not restore a controller or device left in the failed state.
- Initialize the CAN channel and confirm that initialization succeeded.
- Call
SetValueforPCAN_HARD_RESET_STATUSafter successful initialization and set it active (ON). - When the affected state occurs, first record the channel status and independent capture result.
- Call
CAN_Resetor the class-methodReset. With the hard-reset setting active, this invokes the additional hardware reset. - Resume transmission only after the physical bus is connected and an ACK-capable node is active.
The parameter must be set while the channel is initialized. Setting it before initialization does not follow the required initialization state described for these extra parameters. If the application uninitializes and initializes the channel again, configure the setting after the new successful initialization rather than relying on an earlier session.
Should automatic bus-off recovery be enabled?
PCAN_BUSOFF_AUTORESET automatically returns the device to the bus-on state after bus-off. Configure it with SetValue after the CAN channel initializes successfully. It targets the restart-related failure directly when the controller enters bus-off and the physical cause has cleared.
| Setting | Effect | Use when | Pitfall |
|---|---|---|---|
PCAN_BUSOFF_AUTORESET |
Automatically brings a bus-off device back to bus-on | Temporary network loss during device restart can trigger bus-off | A continuing short or other bus fault causes repeated recovery cycles. |
PCAN_HARD_RESET_STATUS plus CAN_Reset
|
Adds a hardware reset to the normal queue reset | A controlled application recovery must clear both queues and hardware state | The setting has no intended effect on the reset call unless configured after initialization. |
CAN_Reset without hard reset active |
Empties transmit and receive queues | The controller remains operational and only queued data must be discarded | Queue clearing alone may not recover the affected hardware state. |
Choose automatic recovery when continued autonomous operation after a transient restart is required. Choose an explicit hard reset when the application must log the fault, control the recovery point, and discard pending traffic deliberately. Both can be configured, but recovery logic must prevent stale commands from being retransmitted after process conditions have changed.
How do you verify the resolving branch?
- Run with the PCAN-USB firmware reported for the affected interfaces,
8.6.1, and record the channel initialization result. - After successful initialization, configure the selected recovery parameter or parameters with
SetValue. - Transmit a known frame and verify it on both independent interfaces, not only in PCAN-View.
- Restart the connected devices in the sequence that previously triggered the condition. Record physical connectivity, node power, transmit-call status, controller status, and captures.
- If bus-off occurs, observe whether
PCAN_BUSOFF_AUTORESETreturns the channel to bus-on. For controlled recovery, activatePCAN_HARD_RESET_STATUS, callCAN_Reset, and record the result. - Send a new test frame after recovery. Pass only when both independent interfaces receive it and the channel remains bus-on without unplugging and reconnecting USB.
FAQ
What happens if PCAN-View shows a sent frame but no other CAN interface sees it?
The local display proves that the request entered the PCAN software/device path, not that transmission completed on the wire. Check the physical bus, ACK-capable nodes, transmit result, and bus-off status.
What happens if no CAN node is available to acknowledge a frame?
The transmitter retries, its error counters rise, and the controller can enter bus-off. Restore an active, correctly configured node before testing recovery.
What happens if CAN_Reset is called without PCAN_HARD_RESET_STATUS active?
CAN_Reset empties the channel's transmit and receive queues. It does not perform the additional hardware reset unless PCAN_HARD_RESET_STATUS is active.
What happens if PCAN_BUSOFF_AUTORESET is enabled during a persistent short circuit?
The device attempts to return to bus-on, but the continuing fault can drive it bus-off again in repeated cycles. Repair the physical fault rather than treating automatic recovery as the fix.
How do I verify PCAN-USB bus-off recovery?
Trigger the restart condition, confirm the channel returns to bus-on, then send a new frame. The final verification step is reception of that frame on both independent CAN interfaces without unplugging the PCAN-USB adapter.