Sending canfd, receiving non-canfd (if payload <= 8)
lbeuster opened this issue · 13 comments
I'm sending canfd frames with payload-size <=8 with JavaCan. If I receive these frames with JavaCan in a different process the frames are recognized as canfd.
But CANoe marks these frames as non-FD frames (any probably the linux-can-tools too - see below).
If I use the linux-can-tools to send the canfd frame, then CANoe marks them as FD.
Frames sent by JavaCan with a payload size > 8 are correctly received as FD by JavaCan, candump and CANoe.
What I did:
# CAN 2.0 + cansend
cansend can0 123#00
Output candump: see "[1]" as length
can0 123 [1] 00
# CanFD + cansend
cansend can0 123##000
Output candump: see "[01]" as length
can0 123 [01] 00
Output JavaCan on receiver side: CanFDFrame(ID=123, FLAGS=4, LEN=1, DATA=[00])
CANoe: shows CanFD
-> everything's fine
-> seems like the can-tools use this special length format for canfd - but that's only a guess.
# CanFD + JavaCan
val client = CanChannels.newRawChannel().apply {
setOption(CanSocketOptions.FD_FRAMES, true)
bind(NetworkDevice.lookup("can0"))
}
client.send(CanFrame.create(291, CanFrame.FD_FLAG_FD_FRAME, ByteArray(1))
Output candump: can0 123 [1] 00
Output JavaCan on receiver side: CanFDFrame(ID=123, FLAGS=4, LEN=1, DATA=[00])
Output CANoe: no CanFD
So I'm not quite sure where the problem is: something in JavaCan or in my mind? Any ideas?
Used version: 3.3.0/aarch64
Would you be able to provide a regression test reproducing this as a pull request? I should be able to have a look at this by next week
It's no regression test, just the code to reproduce this manually. See README in canfd-test directory.
I cannot confirm that candump detects JavaCAN's FD frames as such. In the candump -L output below you see:
- pair of lines: a non-FD frame with 8 bytes of data sent once with JavaCAN and once with cansend
- pair of lines: an FD frame with 8 bytes of data sent once with JavaCAN and once with cansend
- pair of lines: an FD frame with 11 bytes of data send once with JavaCAN and once with cansend
To me it seems that the FD flag is not being set properly.
(1702687478.648674) vcan0 7ED#0011111111111111
(1702687478.705444) vcan0 7ED#0011111111111111
(1702687484.148808) vcan0 7ED#0011111111111111
(1702687484.201471) vcan0 7ED##400111111111111110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(1702687488.149807) vcan0 7ED##40011111111111111222222
(1702687488.201676) vcan0 7ED##400111111111111112222220000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Please test the latest snapshot (https://oss.sonatype.org/content/repositories/snapshots/tel/schich/javacan-core/3.3.1-SNAPSHOT/javacan-core-3.3.1-20231216.013458-4.jar)
Thanks, works now, verified with candump.
# canfd, sent with JavaCan
vcan0 123 [02] 00 00
# no canfd, sent with JavaCan
vcan0 123 [2] 00 00
great, I'll publish a release later today or tomorrow
https://github.com/pschichtel/JavaCAN/releases/tag/javacan-3.3.1
The jars might still need some time to propagate to maven central.
3.3.1 still not available at maven-central, maybe something went wrong?
Weird, I'll check that. I haven't upgraded my own project to. 3.3.1 yet, I'll check this and get back to you here
Apparently something get's messed up in maven's release plugin since my recent plugin updates.... more reasons to go for #45 ... 3.3.2 should eventually land in central. I'll check back later to see if it worked out.
the directory index in central is a little messed up, but the jar is available now
Thanks, 3.3.2 is available and works as expected. ...and thanks for "re-adding" the arch-auto-detect feature - if you use Java to access the CAN, you really don't care about program size ;)
the removal was never about program size, I removed it because it was (and still is) unfixably broken for some architectures. The new solution is a best effort, but it's now just one option instead of the only way.