The simultaneous loss of all CANopen heartbeats points to a latched PC-side communication path, not forty independent motor failures. Closing and reopening the application leaves the USB device, driver, hub, and API state intact; physical USB disconnection forces re-enumeration and restored communication in this installation. Treat the hub, adapter state, driver/API boundary, and CAN error state as separate layers, then remove them from the fault path one at a time.
Symptom quantities and fault boundaries
The number that matters is the count of nodes that stop at the same instant. One missing heartbeat directs attention to that node, its branch wiring, or its configured heartbeat timing. All 40 heartbeats disappearing together moves the first diagnostic boundary upstream to the common PCAN-USB channel, its USB connection, or the software stack controlling it.
The system has a USB2 hub feeding two PCAN-USB adapters, with each adapter connected to 40 motors. Record whether one 40-motor network fails or both fail together. A single-channel event follows that adapter, CAN wiring, or application channel; a two-channel event implicates shared resources such as the hub, host controller, power path, or application process.
| Quantity or state | Limit or decision point | Where to read it | Diagnostic meaning |
|---|---|---|---|
| Missing heartbeat count | One node versus all 40 nodes | Application trace or CAN monitor | Separates a node fault from a channel-wide interruption |
| Affected PCAN-USB channels | One adapter versus both adapters | Separate capture for each channel | Identifies an adapter-specific or shared USB-side fault domain |
| CAN error state | Increasing errors, passive state, or bus-off indication |
PCAN-View status and error display |
Distinguishes CAN electrical failure from a silent host path |
| USB supply and loading | Measured voltage and current against the hub and port ratings | Hub label, hub datasheet, and USB power measurement | Finds voltage drop, current limiting, and marginal hub power |
| Driver, firmware, and API versions | Installed versions versus the current supported package | Driver properties, adapter information, and DLL file properties | Finds mixed or obsolete software components |
| Failure duration | Time from startup to dropout and time since last recovery | Timestamped application and host logs | Exposes thermal, load-related, or cumulative resource behavior |
USB, API, and CAN failure mechanism
A USB application close normally releases application handles, but it does not necessarily power-cycle the hub port, reload the kernel driver, reset the adapter firmware, or clear a host-controller fault. That explains why reopening software can reproduce the dead state immediately while unplugging the adapter restores traffic. Uninstalling the device and rescanning also restored communication here because re-enumeration rebuilt more of the device path than an application restart.
Optical decoupling separates relevant electrical domains at the CAN interface, but it does not make the USB hub, host controller, driver, or application API independent. The two adapters still share a hub-level power and data path. The number that matters is the hub voltage at the adapters while both channels are active, compared with the hub manufacturer's rating; a product label or datasheet supplies the limit.
CAN-side faults can still stop traffic. Poor termination, excessive bus loading, wiring intermittency, or repeated transmit errors can drive a controller into an error state. PCAN-View reveals this through received frames and error indications. If the monitor remains silent without CAN errors and the device cannot respond to a reset, move the investigation toward USB enumeration, driver state, and adapter firmware.
Layered diagnostic checks
Capture the failure before disturbing cables. Connect PCAN-View to the same hardware and note frames, status, and displayed errors at the moment heartbeats disappear. Also record whether the application's motor API and PCAN-View can access the channel concurrently; if exclusive access applies, stop the application cleanly before opening the monitor.
Inventory every software layer. The motor manufacturer's API used a DLL that was identified as being from 2012. Updating the API, driver, and firmware allowed operation for a couple of days, but the dropout returned. That result removes a permanently fixed obsolete-library defect from the leading position; it does not remove version compatibility, DLL loading, or long-duration resource behavior from consideration. Verify the DLL actually loaded by the running process rather than relying on a copied file's location.
Check the physical fault domains next. Bypass the USB2 hub and attach each PCAN-USB directly to a PC USB port. Test one adapter at a time, then both, while keeping CAN wiring and application configuration unchanged. If the event disappears only with the hub removed, investigate hub power, cable loss, port stability, and host-controller loading.
Controlled isolation and recovery procedure
- Start timestamped logging for application state, heartbeat reception, both CAN channels, and host USB events. Mark the last valid heartbeat on each network.
- At the dropout, record whether one channel or both channels stopped. Read the channel status and error display in
PCAN-Viewbefore resetting anything. - Issue
ResetfromPCAN-View. In this installation that reset did not restore traffic, which places the fault below a simple CAN-channel reset. - Close the motor application and reopen it. Record the result; application restart alone did not recover the reported failure.
- Re-enumerate the affected device through the operating system. Uninstalling the device and rescanning restored communication in the reported test, providing a recovery option that does not require moving CAN wiring.
- For the next controlled run, remove the USB hub and connect the PCAN-USB directly to PC USB ports. Change no CAN wiring, motor configuration, or application timing during this comparison.
- Repeat with one adapter active and then with both adapters active. This separates per-adapter behavior from a shared hub or host-resource condition.
- Confirm the running application loads the intended current
PCANBasic APIlibrary and that its API, driver, and adapter firmware form a supported combination.
Recovery verification criteria
A brief return of heartbeat traffic proves recovery, not correction. The updated components operated for a couple of days before the event returned, so the verification run must exceed the previous fault-free interval and cover the same operating process. Preserve identical CAN traffic, motor count, application build, and USB topology for each A/B comparison.
Accept a change only when both networks retain heartbeat traffic, no unexplained CAN errors accumulate, and the USB devices remain enumerated without manual recovery. If direct PC ports pass while the USB2 hub configuration fails, repeat the comparison to rule out a one-time disturbance. If only one adapter follows the failure across direct ports and cables, identify it by its serial-number sticker for official support.
Also verify recovery behavior deliberately during a maintenance window. Test PCAN-View reset, application restart, operating-system re-enumeration, and physical reconnection as distinct actions. Their outcomes identify the lowest layer that remains latched.
Recurring diagnostic pitfalls
Replacing the DLL, driver, and firmware together may improve stability but removes the ability to identify which layer changed the result. Record all three versions before and after the change. A claim that each component is “latest” is incomplete until the running process's loaded DLL and the installed driver are checked.
Node count alone does not diagnose CAN capacity. Forty motors may produce acceptable or excessive traffic depending on bitrate, frame frequency, heartbeat periods, PDO configuration, and error retransmissions. Calculate utilization from the configured traffic and confirm it with a capture; the motor count is only an input.
Do not treat optical decoupling as protection against hub voltage drop or a stalled USB device. This is current, thermal load, timing, and retained device state—not only CANopen logic. Likewise, avoid using physical reconnection as the first diagnostic action because it erases the state needed to distinguish CAN errors from USB or driver failure.
FAQ
Can I recover PCAN-USB communication without unplugging it?
Try PCAN-View reset first, then operating-system device re-enumeration. Reset did not recover this installation, while uninstalling the device and rescanning did restore communication.
Does restarting the CANopen application reset the PCAN-USB?
No. Closing and reopening the software did not clear this failure because the USB device, driver, hub port, or adapter firmware can retain state beyond the application's lifetime.
Does opto-decoupling prevent USB hub faults?
No. Optical decoupling at the CAN interface does not remove the shared USB data and power path, so bypass the hub during isolation testing.
Can 40 CANopen motors overload one PCAN-USB channel?
The node count does not answer that question. Read the configured bitrate and message periods, capture actual traffic and retransmissions, and calculate bus utilization from those quantities.
Does installing the latest driver permanently fix heartbeat dropouts?
Not by itself. The driver, adapter firmware, and PCANBasic API were updated here, but the failure returned after a couple of days, so verify the complete loaded stack and test the hub-free topology for longer than that interval.
Stop local troubleshooting when the fault follows one adapter across direct PC ports, re-enumeration repeatedly becomes necessary, or the device no longer responds to the manufacturer's diagnostic software. Escalate through PEAK-System's official support channel with the PCAN-USB serial-number sticker photo, installed driver/API/firmware details, USB topology, timestamped error status, and the direct-port comparison results.