0

I'm trying to communicate with an actuator device via CAN FD connection, with the help of a Raspberry 4b and a Waveshare CAN hat.

While they are separated, using a tester I read the correct frames on both devices. But when the Raspberry and the actuator are connected, I receive frames with unexpected ID, data and size on the Raspberry.

The code:

import time
import os
import can
import cantools

def startBus():
    os.system('sudo ip link set can0 up type can bitrate 500000   dbitrate 5000000 restart-ms 1000 berr-reporting on fd on')
    time.sleep(0.1)
    global can0
    can0 = can.interface.Bus(bustype='socketcan', channel='can0', bitrate=500000, dbitrate=5000000 receive_own_messages=False, local_loopback=True,
                                    fd=True, can_filters=None, ignore_rx_error_frames=False)

def shutDownBus():
    os.system('sudo ifconfig can0 down')
    print('shut down')

def periodicSend():
    print('sendPeriodic')
    messageID1 = 0xC0FFEE 
    data1 = [0, 1, 2, 3, 4, 5, 6, 7]
    msg1 = can.Message(arbitration_id=messageID1,
                            is_fd=True,
                            data=data1,
                            is_extended_id=False)

    messageID2 = 0xC0FFFF  
    data2 = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
    msg2 = can.Message(arbitration_id=messageID2,
                            is_fd=True,
                            data=data2,
                            is_extended_id=False)

    task1 = can0.send_periodic(msg1, 0.01)

    if not isinstance(task1, can.ModifiableCyclicTaskABC):
        task1.stop()
        return

    task2 = can0.send_periodic(msg2, 0.01)

    if not isinstance(task2, can.ModifiableCyclicTaskABC):
        task2.stop()
        return

def listen():
    print("listening")
    for message in can0:
        print(message)

# Calling the functions: 
shutDownBus()
time.sleep(1)
startBus()
periodicSend()
listen()

x = False
while not x: time.sleep(0.1)

The contents of the received frames:

Timestamp: 1667826218.955793 ID: 0088 S Rx E DL: 8 00 00 94 00 00 00 00 00 Channel: can0
Timestamp: 1667826218.955... ID: 0088 S Rx E DL: 8 00 00 90 00 00 00 00 00 Channel: can0
Timestamp: 1667826218.955... ID: 0088 S Rx E DL: 8 00 00 04 00 00 00 00 00 Channel: can0
Timestamp: 1667826218.955... ID: 0088 S Rx E DL: 8 00 00 02 00 00 00 00 00 Channel: can0

And so on, the third byte keeps changing. These are different from what I am expecting and what I am seeing on the tester (the tester shows the correct frames).

I tried to change the bitrates (500k and 5000k), though I'm rather sure these are correct.

It does not look like a hardware issue, as when separated, both are sending the expected frames.

Setting the ignore_rx_error_frames to False makes the messages disappear, but obviously it is not the solution.

Changing the local_loopback has no visible effect.

Some seemingly similar issues were related to the ACK bit (Sending messages with different ID on a pcan can bus, using python can), but 1) I don't see where and how I could manipulate this and 2) already the very first frame on the bus is not what I am expecting.

Any ideas would be greatly appreciated.

Tawhiri
  • 11
  • 2
  • What do you mean with "error frames"? The term has a well-defined meaning in the context of CAN, as a sequence of 6 bits with the same signal level. They do not contain any information. Do you actually refer to some application layer error messages? – Lundin Nov 10 '22 at 09:28
  • As for hardware issues, the obvious concern is how you place the terminating resistors when just communicating between 2 nodes compared to when you are communicate with 3 nodes. Here is a beginner guide/FAQ about CAN problems: [What are the most common causes of CAN bus communication errors?](https://electrical.codidact.com/posts/276251) – Lundin Nov 10 '22 at 09:30
  • You are right, these are not error frames. The `error_frame = True` property confused me. I corrected the question. – Tawhiri Nov 11 '22 at 05:31
  • Thanks for the linked guide. I don't think any of these are causing my problem. The resistors are ok at both ends. – Tawhiri Nov 11 '22 at 05:34
  • Do you have multiple nodes sending out identical frames at the same time? – Lundin Nov 11 '22 at 07:45
  • One of the nodes (the Raspberry) is sending a single frame. At this moment I'm not sure about the other node (actuator device), it might be sending only two different, or several, including the one being sent by the Raspberry. I will check it on Monday. Can this be the cause of the issue? – Tawhiri Nov 11 '22 at 08:15
  • If two nodes send the same identifier at the same time, but with different payloads, you will get error frames as a result. – Lundin Nov 11 '22 at 08:44

1 Answers1

1

The solution was to adjust the sample-point and the dsample-point parameters when setting up the CAN interface:

sudo ip link set can1 up type can bitrate 500000 dbitrate 5000000 restart-ms 1000 berr-reporting on fd on sample-point .8 dsample-point .8

Apparently CAN FD is more sensitive to these parameters.

Tawhiri
  • 11
  • 2