Image by Mediamodifier from Pixabay

I am using the  Komodo CAN Duo Interface with a Python script that I wrote. The script is based on one of the examples provided in the Komodo Software API library. It worked very well until I increased the emission frequency of my CAN nodes.

When I have only one node on the bus that emits just one CAN frame, the Komodo interface properly receives the CAN frame when it is emitted at 100Hz, 200Hz, and 500Hz. However, at 1kHz, I get infinite loops of errors. Here is an example:

I am not using threads to execute simultaneous commands. I am only running a while loop with the function km_can_read and saving the received CAN frame in a file. Can you tell me what causes the errors at higher frequencies and how I could resolve that limitation?

Thanks for your question! We have two recommendations for your data overflow. To understand monitoring the CAN bus, we will also describe what can cause overflow, as well as how the Komodo interface captures data.

Options for Resolving Data Overflow

An overflow can occur when the Komodo device receives asynchronous messages faster than the rate that can be processed: the receive link is saturated. This condition can also affect other synchronous communication with the Komodo interface.

Here are two simple ways to manage the saturation problem:

• The simplest option is reducing the amount of traffic that is sent by all CAN nodes between calls to the Komodo API. This method requires reconfiguring the offending CAN device(s).
• Another option is polling the CAN channel to collect pending messages more frequently. This way, less data is stored in memory.

Writing and Reading Data Asynchronously

You can also look into the Application Notes section of the Komodo CAN Interface User Manual  for information about threading and scheduling delays. Take a look at this API code, and see if it could help your operation.

This example uses km_can_write. This function acts as a wrapper for the asynchronous submit and collect functions.

km_can_async_submit(komodo, channel, flags,
                    packet, num_bytes, data);
km_can_async_collect(komodo, KM_TIMEOUT_INFINITE,
                     arbitration_count);

• The CAN packet is submitted asynchronously.  km_can_async_collect is called with KM_TIMEOUT_INFINITE to block indefinitely until a response is received.
• A KM_CAN_ASYNC_PENDING error is returned if there are any uncollected asynchronously submitted packets. Packets submitted with km_can_async_submit should always be collected using km_can_async_collect.

Buffering and Capturing Data

Overflow occurs when the amount of data exceeds how much can be buffered.

There is buffering within the Komodo DLL, on a per-device basis, which helps capture asynchronous messages. Take the case of the Komodo interface receiving CAN messages asynchronously. If the application calls the function to change the state of a GPIO while some unprocessed asynchronous messages are pending, the Komodo interface will modify the GPIO pin but also save any pending CAN messages internally. The messages will be held until the appropriate API function is called.

The Komodo interface can be configured as an active CAN node or as a passive monitor. A CAN channel can receive messages asynchronously with respect to the host PC software. Between the calls to the Komodo API, these messages must be buffered somewhere in memory. This is accomplished on the PC host, one of the functions of the operating system. The buffer is limited in size. When the buffer is full, bytes of data will be dropped.

We hope this answers your questions. Additional resources that you may find helpful include the following:

• Komodo CAN Interface User Manual
• CAN Background

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.