Canny to support CAN FD

[ghubmlafontaine]

In relation to the CAN bus speed ajustment functionality there is a new CAN FD protocol that deals with faster network and capacity.

It would be nice that canny be able to extend CAN FD over tcp/ip like is does for regular CAN bus

Thanks for your consideration on this feature.

[m10k]

Hello @ghubmlafontaine,

thank you for the feature request. I completely agree that CAN-FD is something that canny should support in the future.
I put this on my list to implement after the bus rate detection. In the meanwhile I'll try to get a CAN-FD adapter. :)

Best regards

[m10k]

Hey there,

I have just merged a set of commits into the unstable branch that enable CAN-FD support in canny. It seemed to work correctly in tests with virtual interfaces, but I'll do some more testing with physical interfaces in a bit.

The change comes with a big caveat, though: because there are two different types of CAN frames sent over the network, and canny would not be able to distinguish between a normal CAN2.0B frame and a short CAN-FD frame, I had to modify the format of messages that are sent over the network. This means that CANFD-enabled canny versions are incompatible with non-CANFD canny versions. Also, applications that talk to canny over the network will need to be modified to handle the message format correctly.
I understand this is not ideal, so please let me know if this change is acceptable for you. In the meanwhile, I'll have a look if there's an easier way to distinguish between frames.

Best regards

[ghubmlafontaine]

This means that CANFD-enabled canny versions are incompatible with non-CANFD canny versions.

That is a fair limitation. But I would say going forward, it is the CAN-FD flavor that will drag interest. Because thanks to you, the canny "CAN-to-CAN" app you created foot the bill perfectly well.

For the CAN-FD flavor of canny the ideal would be that a CAN-FD-to-CAN-FD app and adapter be able to both find and detect whether the other side is CAN or CAN-FD and adapt.

It would be nice If we could find a white paper that covers the CAN / CAN-FD switch back and forth similar to the one you found for the auto speed detection. I will start searching on my side.

early in may, I will set up a lab to allow me to test the CAN-FD to CAN-FD flavor. I look forward to this.

Thanks to you!

[m10k]

Hey @ghubmlafontaine,

thank you for your feedback! And sorry, I think my explanation might have been a bit misleading.
So the way I implemented CAN-FD support, canny can talk to traditional CAN-2.0B interfaces and CAN-FD interfaces at the same time. However, because the message format on IP-connections has changed, other the canny on the other side of the network needs to be updated.
If your setup has only cannys talking to each other, there should be no problems. However, if you have other software that talks directly to canny over an IP-connection, that software would need to be modified to support the new message format.

The other (obvious) limitation is, that canny won't be able to forward CAN-FD frames to a CAN-2.0B interface. So for example, if you have a setup like the following, the CAN-FD frames will received frames from the CAN-2.0B network, but not the other way around.

+------------------+     +-------+   IP-network   +-------+     +----------------+
| CAN-2.0B network |<--->| canny |<==============>| canny |<--->| CAN-FD network |
+------------------+     +-------+                +-------+     +----------------+
     ^                                                                       ^
     |                                                                       |
    Will not receive messages from the other network                         |
                                   Will receive messages from the other network

So I guess my question is, do you have any custom software that talks to canny over the IP-network? And if so, is there something I can implement to help you port software to the new message format? I'm thinking maybe a small library or something that can be used to establish connections and exchange messages with canny servers would be a worthwhile addition.

Best regards

[ghubmlafontaine]

Hello Mr Kruk,

Thanks for the additional informations. It actually meets all the forseen requirements. Our proof of concept lab connects two CAN network together with only one device on each side. We expect that each device will eventually be upgraded to CAN-FD to improve the speed. We don't have custom code or special addition to the generic canny.

I look forward to be able to test it with CAN-FD somewhere in may. I won't miss updating you on the results.

Thanks again for this update. It's well appreciated

M.L.

[ghubmlafontaine]

Good morning,
Finally, I I was Ible to get a minilab back in place. I dont have yet a CAN-FD to CAN-FD set up in place. We are still searching to find two CAN-FD systems that would fit our lab environment.
I downloaded the canfd-support branch and I wasn't able to have it running ok. here is what I found:
1- First I saw the new -v option... which I liked a lot. It is wery usefull thanks for this addition.

2-I am starting canny in a bash sh, keeping the window opent (option -d). I notice in this version that while in wait state, if I type in that window, it immediately fails canny. That wasn't the case with the previous version.

3- When connecting, everything seems ok but when we start communicating, ( from the caller side) we get the following error (see picture) [ERR] send: Socekt oeration on non-socket

This is happening on a
Raspberry Pi 4 with Pican3

Is it because I am on a PICAN3?

I have ordered Pican FD cards so I will be able to test Pican 3 to Pican FD cards soon. I'll do that while waiting for a real CAN-FD test environment.

Regards

Marc L.

[jagauthier]

I am seeing that same issue.