Problems with player.py

[Ralph-Ne]

Hi guys,

I've got some problems with the newest version of the player in python-can.

The call is the same: python -m can.player -b 250000 -c can0 -v -i socketcan FILE_TO_PLAY

If I use version 2.1.1dev0, downloaded over a year ago, the player works fine, even without the -g option.

If I use the newest version 3.3.1, the player ends with:

Timestamp: 1504177560.972875 ID: 0000 S E DLC: 0 Channel: 0
Timestamp: 1504177560.973315 ID: 0000 S E DLC: 0 Channel: 0
Traceback (most recent call last):
File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/usr/lib/python3.7/site-packages/can/player.py", line 98, in
main()
File "/usr/lib/python3.7/site-packages/can/player.py", line 89, in main
bus.send(m)
File "/usr/lib/python3.7/site-packages/can/interfaces/socketcan/socketcan.py", line 633, in send
raise can.CanError("Transmit buffer full")
can.CanError: Transmit buffer full
[canplayer@canplayer-pc ~]$

If I use the -g option it works, if I do -g 0.01: python -m can.player -b 250000 -c can0 -v -i socketcan -g 0.01 FILE_TO_PLAY,

-g 0.001 or -g 0.0001 lead to the same error as above.

Can you imagine what I've done wrong? Do you have any advice for me to solve the problem?

Kind regards

Ralph

[mikado98765]

If they aren't proprietary, could you post the contents of FILE_TO_PLAY, or what format its in? Not working without -g makes sense because if it's not provided, it's set to .0001 by default

[Ralph-Ne]

CAN_JD670i_j1939_2017-08-31_13-06-00.blf.zip

[mikado98765]

I've tried the file on a different interface and it appears to work. The smaller values of g probably mean that messages are getting sent too fast, filling up the tx buffer, as the error suggests. Are you using a virtual or physical device? Possibly helpful link: http://socket-can.996257.n3.nabble.com/increase-buffer-size-td2024.html
As the link suggests, if you're on linux, you can use ifconfig to see the txqueuelen.
(fyi, it looks like the blf file sends about 1000 msgs in .6 seconds)

[Ralph-Ne]

"ip link set can0 up txqueuelen 1000" is set in both cases, "slcand -o -c -f -s5 /dev/ttyUSB0 can0" to bind the device, so that "can0" appears when I do "ip addr"
The device, which analyses the data from the canplayer via the USB-adapter is a physical one.
If I use the player.py-2.1.1 it works fine, but player.py-3.3.1 is much to slow to play the data in the *.blf file in time.

[christiansandberg]

Does the log contain error frames? One difference with the BLF parser is that it recognizes error frames in the log and will therefore add them to the socketcan transmit queue, possibly faster than can be processed. Obviously you can’t send error frames on a physical bus, but it’s possible on a virtual.

[Ralph-Ne]

Yes, the log contains error frames. It's a normal log from a farm machine with error and "good data" frames. But why they are treated particulary?

[christiansandberg]

Error frames are treated like regular frames basically, but what happens when trying to send an error frame is interface dependent. Mostly they will probably be discarded by the driver.

I’m thinking however that the player should by default not send error frames, but it could be enabled by a switch if desired.

[Ralph-Ne]

Which switch I have to use to enable error frames?

[felixdivo]

Seems like it would be --error-frames.