CAN-to-UDP vs Cannelloni

[AvA-66]

Goodevening sir, I am looking to connect my local Windows pc to the canbus of a remote Lenze frequency drive. This remote frequence drive is controlled over can0 of an also remote Linux embedded controller running Codesys. Using cannelloni, this can0 is sent over Ethernet UDP, via a VPN connection, to a local identical embedded controller, which is using cannelloni to convert Ethernet UDP to its can0. With candump I see the canbus messages scrolling by. I can also connect the PCAN-USB converter in an attempt to connect the Lenze Easystarter drive-setup software to the frequency drive (as I would normally do when I am near the drive). However, it does not recognise the drive and I am wondering why, The remote canbus is at 500kbps with a 10ms sync (verified with PCAN-USB), but the local canbus runs much faster at about 1.5ms. Also, the remote can0 080h sync is not showing on the local can0. Maybe that's why Easystarter cannot connect?

Anyway, would it be possible to use the LELY CAN-to-UDP tool for this job? Can it be build for an embedded system? Would it also transfer the sync pulses and adhere to the 10ms canbus cycle?

Appologies for the long message, I hope you can find a couple of minutes to look into it.

Best regards, Arnold

[olerem]

Hi Arnold,

1. If I understood correctly, your hardware setup can be represented as follows:

|----------------|  CAN bus 500kbps  |----------------|   UDP over   |------VPN------|   UDP over   |----------------|  CAN bus   |----------------|
| Lenze frequency|  <--------------->| Linux Embedded | <----------->|      LAN      | <----------->| Linux Embedded | <--------->| PCAN-USB to    |
|      drive     |                   |    Controller  |    LAN       |               |    LAN       |    Controller  |            | Windows PC     |
|                |                   | (running CODESYS)              |               |              |                |            | (running Lenze |
|                |                   |----------------|               |               |              |----------------|            |  Easystarter)  |
|----------------|                                                             VPN                                             |----------------|

2. Regarding the "080h sync" and its relation to the CAN bus speed, it's unclear to me exactly what it represents, but I assume it's related to the timing or synchronization on the CAN bus. If we presume it's related to bus speed and given that your local bus sends messages roughly 6.67 times more frequently than the remote bus (10ms remote sync interval / 1.5ms local sync interval), the local CAN bus would need to operate approximately 6.67 times faster than the remote one to handle the same amount of data per message. That would put the local bus speed at around 3.335Mbps (500kbps remote speed * 6.67).

3. As for the configuration of the CAN bus bitrate, this is typically managed via the ip command in Linux and not by the CAN-to-UDP software. Here's an example of how you might set the bitrate of a CAN interface to 500kbps:

ip link set can0 type can bitrate 500000
ip link set can0 up

Please replace "can0" with the appropriate interface name for your setup. You'll want to adjust the bitrate according to your needs, and you may require root or sudo permissions to run these commands.

Please note that these suggestions are based on assumptions due to the limited details available. If you can provide more specific information, I might be able to provide a more accurate answer.

[AvA-66]

Hello Oleksij,

Thank you very much for your fast reply! Appologies for my delay in response, it's a bit hectic these days.

You have understood the setup 100% correct, I will explain some more. I am using CANopen in which the sync message is generated by the remote CANbus master at PID 080h every 10ms. The sync is used to initiate the communication between the CANbus participants. At each sync all participants (master and slaves) communicate their RPDO's and TPDO's.

If I connect the PCAN-USB converter to the remote canbus (verified at 500kbps), I see these sync pulses in the receive list of PCAN-View at the expected cycle time of 10ms, along with the PDO's of the other participants, so all is good. However if I connect that same PCAN-USB converter to the local canbus (also verified to be at 500kbps), I see no sync pulses anymore, only the participants PDO's, and at a cycle time of 1.5ms. But why the change in cycle time? The PCAN-View manual says: "Cycle Time = Time interval between the last two received messages with the same ID, in Milliseconds." I am sure the canbus is active at 500kbps, because that is what the PCAN-View is showing in the status bar while it is receiving canbus messages.

According to the manual of my embedded Linux controller: "Due to the use of the busybox version of the ip tool the "ip link set" sequence does NOT work on the Garz & Fricke Linux systems". Instead they have canconfig tool for that job, which I am using also.

Latest update: If I use the cannelloni connection over a direct Ethernet cable connection, so no VPN, I am able to connect the Lenze Easystarter software to the frequency drive. I don't understand why it does not work over a VPN.

Maybe the problem is in the cannelloni software, that it somehow disregards the cycle time?
Do you know if the LELY CAN-to-UDP tool behaves differently?

Best regards, Arnold

[olerem]

Hello Arnold,

Thanks for explaining your situation. Based on what we've talked about, I see the possible problem is in the timing of CAN messages when you convert them to UDP and send them over VPN.

When CAN messages change to UDP, the original timing between messages might not stay the same. With UDP, the messages are sent as fast as possible, and the original timing can get lost. When you add in a VPN, this can cause even more delays and maybe even loss of some packets. All of these things can mess up the transmission of important CAN frames, like the sync pulses at PID 080h.

You're seeing this issue with the cycle time changing from 10ms to 1.5ms when you're using a VPN. This faster rate could be because the sync pulse that tells the nodes to slow down is missing. Or, it could be because of other things affecting the cycle time.

To fix this, you might need to change the existing tools you're using or even make a new solution. If you can modify the software you're using, like cannelloni or LELY's CAN-to-UDP tool, you could try to make it fit your needs. You could maybe change the tool to store CAN messages and then release them in a way that keeps the original timing, even when sent over a VPN.

But making a new solution or changing existing tools could be hard. It might require a deep understanding of CAN, UDP, and network programming. This would be a big project and could be complex. You might also want to think about adding in things to make sure packets don't get lost or to correct errors.

If this seems too difficult or if you don't have enough resources, it might be a good idea to think about asking for help from a company that specializes in these issues. For example, the company I work for, Pengutronix, offers services for problems with Linux-based embedded systems. They could maybe help you solve this issue.

I just want to make clear that I'm not trying to sell you anything. I understand this problem is complex, and I'm just offering possible solutions. I hope this makes things clearer for you. If you have any other questions or need more clarification, please ask.

Best regards,
Oleksij

[AvA-66]

Hi Oleksij,

Again thanks for your reply. The lost of sync was also my thought, but since it is working when using a wired connection instead of a VPN, I am not so sure. Same story with the timing of the messages. That's why I would like to give LELY CAN-to-UDP tool a try, possibly that is respecting timing and sync.

The route of designing a specialised tool myself or by a third party is too much, in both money and time, for my planned use of it.

I have build and used the LELY CANopen library on this embedded system, so I'm familiar with the procedure, but the CAN-to-UDP tool seems to be build only for the host system, not for the embedded. Do you know if it can be build for Linux embedded?

Best regards.
Arnold

[drpsec1]

Your data is being encrypted and converted through the vpn service. The ethernet frames will have to be reassembled prior to being interpreted by the can bus interface api. In addition, I might even look into the data transfer rate calculated earlier. As the additional time factor of the vpn service functions will have to be accounted for, or the can interface will be calling for a device that's information is yet to become recognizable due to the security methods of the vpn service.