Signal Driven SocketCAN

[yosoufe]

Hi

I am trying to establish a signal-driven SocketCAN in Linux with C++ as a ROS node. I am facing some issues. First of all I do not have the SIGIO signal for every message. Therefore at the reception of SIGIO I am reading from the socket until there is no message left. This is somehow solvable although It would be nice to know the reason and it may be a cause for the second unsolved problem.

The main problem is that in my signal Driven CAN ROS node, the messages are not sometimes read in the order of the arrival. Sometimes it is not FIFO. But interestingly the timestamp of the message is correct. For example the following image is showing the output of the

Code: Select all

candump can0 -ta -c

on the left side and on the right side the output of my CAN node is shown. As you can see there is a a message in the wrong order (labeled with Time Error: ) on the right side.

please open the image in new tab to see the complete image.

[S.Grosjean]

Hi,

First, please tell us what kind of PEAK-System equipment you're using, in which environment ($ uname -a), and which driver your application is accessing (one of the mainline peak_* drivers or the pcan driver built in netdev mode, and which version) ?

Regards,

Stéphane

[yosoufe]

Hi,
First, please tell us what kind of PEAK-System equipment you're using, in which environment ($ uname -a), and which driver your application is accessing (one of the mainline peak_* drivers or the pcan driver built in netdev mode, and which version) ?

Hi
I am using PCAN-USB now for prototyping but the software should be compatible with PCAN-PCI series.

Code: Select all

$ uname -a
Linux 4.8.0-53-generic #56~16.04.1-Ubuntu SMP Tue May 16 01:18:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

I have installed peak-linux-driver-8.3.1 with the following commands

Code: Select all

make -C driver NET=NETDEV_SUPPORT
make -C lib NET=NETDEV_SUPPORT
make -C test NET=NETDEV_SUPPORT
sudo make install

thanks

[S.Grosjean]

Hi,

Regarding the SIGIO issue, this is a system one. The pcan driver only forwards the CAN packets it reads from the bus to the socket-CAN layer.

Generally speaking, for a recent, up-to-date and fully reliable socket-CAN API, it is advised to use the mainline drivers instead of the pcan driver. To do this, first uninstall the pcan driver. Then, modprobe peak_usb. If one of theses days you'll switch to one of our PCI/PCIe cards, you'll modprobe peak_pci instead.

Regards,

Stéphane

[yosoufe]

Hi

Today I just modified the candump file in a way that it shows as well the negative time difference. the changes are here.
https://github.com/yosoufe/can-utils/co ... 83c03df007

In two or three minutes of execution of

Code: Select all

./candump can0 -td -c

-td would print the time difference of the timestamps.

I got read sequence problem. The following image is the output of the modified candump. It means sometimes the order of the reading from the candump is also wrong and the message which is arrived earlier is read later.



I assume that the candump should be very good example of reading CAN messages. But still I get some errors.

Do you have any idea where this error is coming from? is it from the driver or kernel or my PC or my configurations??

I am loading the CAN module with these commands now

Code: Select all

sudo modprobe peak_usb # peak_pci
sudo modprobe can
sudo modprobe can_raw
sudo ip link set can0 up type can bitrate 500000

thanks for your help

[S.Grosjean]

Hi,

Thanks for your reply. We're running for hours the same testbed than you without any problem (we have added an exit command when the negative cmp occurs to be sure to not miss it).

Meanwhile, I know that ordering of network packets might sometimes be disturbed with multi-core environments. To verify, you could 1/ build or boot your kernel with disabling SMP 2/ setup the smp_affinity of the related USB IRQ to a specific core.

Regards,

Stéphane

[yosoufe]

Thanks again

Interestingly when I tried it today again, I didn't get the error anymore.

[S.Grosjean]

Hi,

Glad to know it. For information, did you upgrade your Linux Kernel recently?

Regards,

Stéphane

[martinkepplinger]

Hi,

I seem to have almost the exact same problem. I need frames to work FIFO but
(after running a simple tx/response at 115000 kbit/s for some time) I see an
out-of-order error, see below. Please note that "hours" may not be enough for
it to trigger but we can repeatedly trigger it. run at least for 1-2 days.

Our application uses Qt 5.9.5's serialbus module which uses Linux socketcan
on the current Debian 4.9 kernel (4.9.0-7-amd64 #1 SMP Debian 4.9.110-1
(2018-07-05) x86_64 GNU/Linux) and it's peak_usb mainline driver.

What you see is the last correct communication (first 4 lines) and the
out-of-order error (last 4 lines). Again, the CAN frame's timestamp shows the
_correct_ order of the frames. Look at the last 3 lines. Linux reads them
in the wrong order though! (415732us > 415213us, but read first).

Code: Select all

read-time                      frame-time          frame-data
               s  ms           s          us
24.07.18-15:24:43.399 - CAN TX 0 0               : "     000   [3]  00 00 FF"
24.07.18-15:24:43.401 - CAN RX 1532438683 401589 : "     000   [8]  00 0F 6C 69 6E 72 70 63"
24.07.18-15:24:43.402 - CAN RX 1532438683 402493 : "     000   [8]  64 32 2D 31 38 2E 30 34"
24.07.18-15:24:43.403 - CAN RX 1532438683 403033 : "     000   [2]  00 9E"
24.07.18-15:24:43.411 - CAN TX 0 0               : "     000   [3]  00 00 FF"
24.07.18-15:24:43.414 - CAN RX 1532438683 414264 : "     000   [8]  00 0F 6C 69 6E 72 70 63"
24.07.18-15:24:43.415 - CAN RX 1532438683 415732 : "     000   [2]  00 9E"
24.07.18-15:24:43.417 - CAN RX 1532438683 415213 : "     000   [8]  64 32 2D 31 38 2E 30 34"

We run candump simultaneously for verification. It sees just the same mistake
(we trigger exit in our own application but watching the timestamps like you
did is equally fine):

Code: Select all

  can0  000   [3]  00 00 FF
  can0  000   [8]  00 0F 6C 69 6E 72 70 63
  can0  000   [8]  64 32 2D 31 38 2E 30 34
  can0  000   [2]  00 9E
  can0  000   [3]  00 00 FF
  can0  000   [8]  00 0F 6C 69 6E 72 70 63
  can0  000   [2]  00 9E
  can0  000   [8]  64 32 2D 31 38 2E 30 34

There are no error frames arriving.

We use the IPEH-002021 USB device, ser.no. 61680 (firmware version 2.8). Might
there be a firmware issue you know of?

We are further investigating, but it seems like there is a real problem.

Do you have further questions? Thanks for any advice,

Martin

[S.Grosjean]

Hi,

The question is: does the last frame really arrives before the previous one or is last timestamp wrong?
Can you check the sequence of the frames with the content of the data byte?

— Stéphane