CAN Interface RKS+CAN / KCANMonitor Bug/Feature Requests

The RKS+CAN is our CAN to USB interface for CAN2.0A, CAN2.0B, ISO 11898-2. Which features should the RKS+CAN hardware for USB or the CAN sniffer KCANMonitor support?

Bug reports are explicitly welcome.

Suggestions are welcome!

Current summary with status:

- Completed: Hardware CAN filter.
- Completed: Added tooltips for more intuitive operation.
- Completed: Trace faster.
- Completed: Providing OBD2 diagnostic data.
- Completed: Provide engine control unit self-test results (readiness).
- Completed: Driver signature for VCP drivers for all Windows versions.
- Completed: Monitor view for finding changing values. Cyclically changing bytes are highlighted in orange, increasing values in dark green, decreasing values in light green, and spontaneously changing values in blue.
- Completed: Import of logs/traces with automatic delays.
- Completed: Signed Windows drivers for XP to Windows 8.1.
- Planned: Make the lists in KCANMonitor sortable.
- Later: CAN-FD, MPC5748G, and MC34901.
- Planned: Execute loadable script code on CAN hardware (without USB usage). For example, cyclically sending messages that are mapped to user-definable variables. Processing of I/O, USB, or CAN events, and state machine functionality.
- Uncertain: Should VAN (Vehicle Area Network, a network similar to CAN, used, for example, within the PSA group) support be provided?
- Planned: PDF manual covering software installation, usage of KCANMonitor, and basic principles of connecting to the CAN bus (wiring, termination).

- Planned: WIFI version (wireless).

A question: Is there already a release date for the WiFi version?

robiwan wrote:

Eine Frage: Gibt es für die WiFi Version bereits einen Releasetermin?

It turned out that wireless versions did not generate the expected demand and did not offer significant advantages without fundamentally changing the entire concept.
However, it remains on the to-do list along with other changes.

Best regards, Rainer.

KCANMonitor Feature Requests:

- Completed: Measurement of operating voltage at the interface.
- Completed: Programming interface updated to asynchronous command processing.
- Planned: CAN-FD support.
- Signal generator
- Graphical representation of signals.
- DBC Import (useful for graphically representing signals)

Best regards, Rainer.

Feature Request:

If the computer is too slow and there are a very large number of CAN messages, allow messages to be dropped. In fast buses with a high bus load, the laptop/PC may be overwhelmed by the message processing, causing the messages to accumulate until nothing can be processed. In this case, it is better to drop messages before the computer becomes unusable or displays an error, and to reduce the volume of messages to be processed by using filters.

Best regards, Rainer.

CAN-Diagnose wrote:

If the computer is too slow and there are a very large number of CAN messages, allow messages to be lost. In fast buses with a high bus load, the laptop/PC may be overwhelmed by the message processing, causing the messages to accumulate more and more until nothing can be processed. In this case, allow messages to be lost before the computer becomes unusable, or provide a warning. Use filters to reduce the flood of messages that need to be processed.

KCANMonitor has been improved to significantly enhance the display of received CAN messages. The number of messages that can be processed without filtering has been greatly increased, without any loss of data.

KCANMonitor, the CAN software for the CAN-USB interface, is now version 2.70, while the version of the RKS+CAN installation package remains the same.

Feature Request:

Terminal window for stdout/stdin via freely definable CAN ID, enabling debug output on boards without an SWD/JTAG debug interface during runtime.

A "printf" statement on the development system will then appear as text output in a "terminal window".

It greatly simplifies understanding the system state when debugging via the usual pins is not possible, because those pins are already being used for other purposes.

Make the columns wider for messages with extended IDs.

"Please provide the text you would like me to translate from German to English."

Tecnoworld wrote:

Hello, I've read everything about the hardware so far, but I'm missing some information. To effectively debug CAN messages, I would need hardware inputs for synchronization. Given that the hardware provides timestamps with a resolution of 10 microseconds, it would make sense to have hardware triggers to trigger events. Conversely, if a CAN filter triggers, I would like to have a real-time output signal to trigger the logic analyzer, oscilloscope, or other hardware. Ist das schon implementiert?

Hello,

No, it is not currently implemented, but it would not be a problem in future hardware versions.

Best regards, Rainer.