I am using Codesys V3.5 SP17 and an Opus A6 as part of a project.
I use a CAN BUS where different frames circulate. The problem I encounter is that I have the impression that the bus is overloaded and that therefore at the RX reception there are losses. There would be a way to increase the size of the Buffer to avoid this problem?
Cordially
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, what target are you using (because SP17 has not been released yet for Opus panels)?
What bitrate are you currently using, and what is the task cycle time associated with message processing? At 250 kbit/s, at most 22 messages can be transmitted every 10 ms (100% busload), so making a buffer hold (say) 500 messages would not solve your problem.
How are you receiving messages, via CL2 functions, via CANopen/J1939 managers or via Topcon special subdevices (TransmitMessage/ReceiveMessage)?
Could you assess your busload (and absence of error frames) with an hardware tool like PCAN USB Pro or Vector CANcase XL?
Could you implement a rolling counter inside your messages and check that they are actually not received? Or log them and compare the log with one from your favourite USB adapter...
"Impressions" do not have any value in CAN debugging, only facts matter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I manipulate the messages thanks to TransmitMessage/ReceiveMessage but also the CL2 functions. The transmitMessage works perfectly, it is when I receive it that I have trouble. I have tested several ways but the problem persists. there are not errors. In fact, the ReceiveMessage receives all the frames but cannot process them all. In the ReceiveMessage device, the LostCounter counter does not increase.For the bitrate , I'm at 250Kbit/s.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The ReceiveMessage holds only the latest received message during the bus cycle.
Solutions:
- reduce the cycle interval of the bus task associated to ReceiveMessage to be less than the message interval, and process messages in that task
- receive the messages via CL2
- if you are using a multipacket protocol for transport, consider switching to CANopen or J1939
The last point does not work for multiplexed messages, where a field marks the content of the messages. Topcon Projektor has native support for this kind of messages, consider it.
👍
1
Last edit: sgronchi 2022-08-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, first you should check which task is used as bus cycle task.
Double click the related CANL2ConfigX, go to the "CANL2ConfigX I/O Mapping" tab and check which task is used (figure 1). If "Use parent bus cycle settings", then double click the main device (the parent of the PLC logic node), then go to "PLC settings tab" and examine which task is selected in "Bus cycle options" (figure 2). If that is "<unspecified>" then it's the cyclic task with the shorter interval in your task configuration.</unspecified>
Then go to the task you identified (figure 3) and set the interval accordingly (figure 4). It should be less than the time between two messages.
You can also create a new task whose job (= the program called) is only processing of the messages and then set that as CANL2ConfigX bus cycle task.
Or you can go the CL2 route: every scan you will be asked to handle every message received from the beginnning of the previous scan.
Hello,
I am using Codesys V3.5 SP17 and an Opus A6 as part of a project.
I use a CAN BUS where different frames circulate. The problem I encounter is that I have the impression that the bus is overloaded and that therefore at the RX reception there are losses. There would be a way to increase the size of the Buffer to avoid this problem?
Cordially
more posts ...
First, what target are you using (because SP17 has not been released yet for Opus panels)?
What bitrate are you currently using, and what is the task cycle time associated with message processing? At 250 kbit/s, at most 22 messages can be transmitted every 10 ms (100% busload), so making a buffer hold (say) 500 messages would not solve your problem.
How are you receiving messages, via CL2 functions, via CANopen/J1939 managers or via Topcon special subdevices (TransmitMessage/ReceiveMessage)?
Could you assess your busload (and absence of error frames) with an hardware tool like PCAN USB Pro or Vector CANcase XL?
Could you implement a rolling counter inside your messages and check that they are actually not received? Or log them and compare the log with one from your favourite USB adapter...
"Impressions" do not have any value in CAN debugging, only facts matter.
Hello sgronch,
I manipulate the messages thanks to TransmitMessage/ReceiveMessage but also the CL2 functions. The transmitMessage works perfectly, it is when I receive it that I have trouble. I have tested several ways but the problem persists. there are not errors. In fact, the ReceiveMessage receives all the frames but cannot process them all. In the ReceiveMessage device, the LostCounter counter does not increase.For the bitrate , I'm at 250Kbit/s.
The ReceiveMessage holds only the latest received message during the bus cycle.
Solutions:
- reduce the cycle interval of the bus task associated to ReceiveMessage to be less than the message interval, and process messages in that task
- receive the messages via CL2
- if you are using a multipacket protocol for transport, consider switching to CANopen or J1939
The last point does not work for multiplexed messages, where a field marks the content of the messages. Topcon Projektor has native support for this kind of messages, consider it.
Last edit: sgronchi 2022-08-26
how exactly do we reduce the interval of the task associated with ReceiveMessage?
Well, first you should check which task is used as bus cycle task.
Double click the related CANL2ConfigX, go to the "CANL2ConfigX I/O Mapping" tab and check which task is used (figure 1). If "Use parent bus cycle settings", then double click the main device (the parent of the PLC logic node), then go to "PLC settings tab" and examine which task is selected in "Bus cycle options" (figure 2). If that is "<unspecified>" then it's the cyclic task with the shorter interval in your task configuration.</unspecified>
Then go to the task you identified (figure 3) and set the interval accordingly (figure 4). It should be less than the time between two messages.
You can also create a new task whose job (= the program called) is only processing of the messages and then set that as CANL2ConfigX bus cycle task.
Or you can go the CL2 route: every scan you will be asked to handle every message received from the beginnning of the previous scan.