CAN bus speed calculation
Raspberry Pi 2 with a HAT PiCAN 2
250kbit/s, 8 identical nodes, 1m
A Bus cycle task for the CANopen manager is a special created task with a cycle time of 10ms
Each Node
Receives 1 PDO and transmits 3 PDO cyclic
Pi produces SYNC
Cycle period 400ms
Windows length 40ms
Pi produces heartbeat.
Producer time 800ms
Each node is set to consume a heartbeat within 1800ms
Assuming that each PDO is sent in one frame of 8 data bytes we get the amount of bits transmitted at every SYNC
112x3=336 bits
and we have 8 nodes in total
336x8=2688 bits
The time used for transmitting is
t=2688/250 = 10.8ms
This is below the window length
However all my slaves sends an EMCY saying that heartbeat not received after a while. If I disable 2 nodes. It all works without problems for days. Why can't I have 8 nodes
When is heartbeat sent? Inside or outside the PDO SYNC window?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can anyone explain how the CANopen manager schedules the PDO for each node at every PLC cycle. What happens if the CANBus controllers buffer is full (PiCAN2 is using MCP2515)?
It seems only a limited number of frames from the master can be sent from the master, one for each node of total 6. Above that after a while the transmitting from the Pi just stops.
The CANOpen Manager version 3.15.17.0 does not it seems scale well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From my experience, this is usually a low level problem, can mini driver loses messages.. as soon you have higher load on CANbus. ( This is not a problem of the CANopen Manager)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are talking about cyclic PDO. It means a loss of some frames (messages) is not a problem. The problem is that in the above example the transmitting of any message PDOs or heartbeat from the master simply stops and a warm reset has to be done.
I don't think the load in the above example is high. However, it can be the driver (or stack) for the can bus, which cannot figure out to queue messages properbly if they come fast from the CANOpen_manager.
I will later try it out with a newer version (Bullseye) and see what's happen.
I also think, but not yet tried I can with a python script test the communication with 250kbit/s without any problem, though with some loss of frames.
It would be wonderful if I could instruct the CANOpen_manager to wait at least 1ms between every frame it sends.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We have now discovered. That enabling of the I2C interface and after adding an I2C_master but without any devices will have an impact on the traffic on the spi interfaces (or the canopen manager) and here by on the traffic on the can bus as well. We thought that the OS or CODESYS behind the scene with a critical region or semaphores ensured protection of the above. Because in the above example we had an I2C_master as well as one device. Without any I2c_master it can run for days, with an I2C_master only for <3 hours
Last edit: DavidBo 2023-04-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
CAN bus speed calculation
Raspberry Pi 2 with a HAT PiCAN 2
250kbit/s, 8 identical nodes, 1m
A Bus cycle task for the CANopen manager is a special created task with a cycle time of 10ms
Each Node
Receives 1 PDO and transmits 3 PDO cyclic
Pi produces SYNC
Cycle period 400ms
Windows length 40ms
Pi produces heartbeat.
Producer time 800ms
Each node is set to consume a heartbeat within 1800ms
Assuming that each PDO is sent in one frame of 8 data bytes we get the amount of bits transmitted at every SYNC
112x3=336 bits
and we have 8 nodes in total
336x8=2688 bits
The time used for transmitting is
t=2688/250 = 10.8ms
This is below the window length
However all my slaves sends an EMCY saying that heartbeat not received after a while. If I disable 2 nodes. It all works without problems for days. Why can't I have 8 nodes
When is heartbeat sent? Inside or outside the PDO SYNC window?
Can anyone explain how the CANopen manager schedules the PDO for each node at every PLC cycle. What happens if the CANBus controllers buffer is full (PiCAN2 is using MCP2515)?
It seems only a limited number of frames from the master can be sent from the master, one for each node of total 6. Above that after a while the transmitting from the Pi just stops.
The CANOpen Manager version 3.15.17.0 does not it seems scale well.
From my experience, this is usually a low level problem, can mini driver loses messages.. as soon you have higher load on CANbus. ( This is not a problem of the CANopen Manager)
We are talking about cyclic PDO. It means a loss of some frames (messages) is not a problem. The problem is that in the above example the transmitting of any message PDOs or heartbeat from the master simply stops and a warm reset has to be done.
I don't think the load in the above example is high. However, it can be the driver (or stack) for the can bus, which cannot figure out to queue messages properbly if they come fast from the CANOpen_manager.
I will later try it out with a newer version (Bullseye) and see what's happen.
I also think, but not yet tried I can with a python script test the communication with 250kbit/s without any problem, though with some loss of frames.
It would be wonderful if I could instruct the CANOpen_manager to wait at least 1ms between every frame it sends.
We have now discovered. That enabling of the I2C interface and after adding an I2C_master but without any devices will have an impact on the traffic on the spi interfaces (or the canopen manager) and here by on the traffic on the can bus as well. We thought that the OS or CODESYS behind the scene with a critical region or semaphores ensured protection of the above. Because in the above example we had an I2C_master as well as one device. Without any I2c_master it can run for days, with an I2C_master only for <3 hours
Last edit: DavidBo 2023-04-18