Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
i'm using the CanOpenManager to communicate with my devices (5pcs). Unfortunately the Manager sends a ResetNode to all of my devices without any reason. The time between the ResetNode-cmd is very random -> could be a few minutes to few hours!!?!
I've made lot's of canbus-traces, can see the ResetNode-cmd by the Manager but can't find any reason for the reset-cmd ...
-> so my last guess is that there is a intermittet failure on the bus and the manager sends the reset within less than one second!?!
-> is it possible to modify the timeout of the CanOpenManager that the ResetNode is sent only after a few seconds
br,
Andy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
which plc in which version are you using?
Could you enable CANOPEN_DEBUG as compiler define ( not needed =>3.5SP16
Then attach the plclogger - maybe the can trace too.
"Unfortunately the Manager sends a ResetNode to all of my devices without any reason"
without a reason, the manager certainly doesn't
There will be a heartbeat error probably?!
BR
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i'm using 3.5/SP10 .. i have to stick to that version because the ecu-supplier (TTControl) only supports that version
"without a reason, the manager certainly doesn't" -> :) i guess so, but i can't really reproduce the issue and depending on my can-traces i can't really naildown any bus-errors or similar.
my master is producing a heartbeat with 500ms -> upon simulated buserrors the CanOpenManager sends the ResetNode within less than 1sec (guess 1,5*500ms)
-> how is the hb-timeout in the CanOpen Manager calculated?
-> so IMHO increasing the errorthreshold/hb-timeout up to 3sec would probably fix my sporadic buserrors(missing node-hb)?!
-> should i set asymetric hb-times (master=500ms, nodes=100ms)?
a restart of the can-nodes is very 'bad' in our application therefore i'm looking for a more forgiving behaviour of the CanOpenManager
Last edit: neapolitaner 2020-07-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
finally i found the issue ... on my CAN-bus there are several CanOpen and J1939 devices. To keep the busload as low as possible i set the CanOpen PDO's to different interval-times. Therefore every few minutes/hours (depending on the chosen timings) all PDO's need to get handled at the same time.
This "spike" in bus-load and especially cpu-load required way too much processing-time and exceeded the cycletime of the CPU.
means: i've chosen 10ms as minimum CPU taskcycle
during "spike": the CPU taskcycle-time took up to 14ms and probably messed up the internal timing/statemachine of the CanOpenManager
solution: i've set the CPU-taskcycle-time to 20ms and since that modification everthing is fine!
br,
Andy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i'm using the CanOpenManager to communicate with my devices (5pcs). Unfortunately the Manager sends a ResetNode to all of my devices without any reason. The time between the ResetNode-cmd is very random -> could be a few minutes to few hours!!?!
I've made lot's of canbus-traces, can see the ResetNode-cmd by the Manager but can't find any reason for the reset-cmd ...
-> so my last guess is that there is a intermittet failure on the bus and the manager sends the reset within less than one second!?!
-> is it possible to modify the timeout of the CanOpenManager that the ResetNode is sent only after a few seconds
br,
Andy
Hi,
which plc in which version are you using?
Could you enable CANOPEN_DEBUG as compiler define ( not needed =>3.5SP16
Then attach the plclogger - maybe the can trace too.
"Unfortunately the Manager sends a ResetNode to all of my devices without any reason"
without a reason, the manager certainly doesn't
There will be a heartbeat error probably?!
BR
Edwin
i'm using 3.5/SP10 .. i have to stick to that version because the ecu-supplier (TTControl) only supports that version
"without a reason, the manager certainly doesn't" -> :) i guess so, but i can't really reproduce the issue and depending on my can-traces i can't really naildown any bus-errors or similar.
my master is producing a heartbeat with 500ms -> upon simulated buserrors the CanOpenManager sends the ResetNode within less than 1sec (guess 1,5*500ms)
-> how is the hb-timeout in the CanOpen Manager calculated?
-> so IMHO increasing the errorthreshold/hb-timeout up to 3sec would probably fix my sporadic buserrors(missing node-hb)?!
-> should i set asymetric hb-times (master=500ms, nodes=100ms)?
a restart of the can-nodes is very 'bad' in our application therefore i'm looking for a more forgiving behaviour of the CanOpenManager
Last edit: neapolitaner 2020-07-22
Hi neapolitaner
Did you ever find a solution to this problem? I am currently facing a similar situation.
Hi neapolitaner
Did you ever find a solution to this problem? I am currently facing a similar situation.
Hi neapolitaner
Did you ever find a solution to this problem? I am currently facing a similar situation.
Hi neapolitaner
Did you ever find a solution to this problem? I am currently facing a similar situation.
hi,
finally i found the issue ... on my CAN-bus there are several CanOpen and J1939 devices. To keep the busload as low as possible i set the CanOpen PDO's to different interval-times. Therefore every few minutes/hours (depending on the chosen timings) all PDO's need to get handled at the same time.
This "spike" in bus-load and especially cpu-load required way too much processing-time and exceeded the cycletime of the CPU.
means: i've chosen 10ms as minimum CPU taskcycle
during "spike": the CPU taskcycle-time took up to 14ms and probably messed up the internal timing/statemachine of the CanOpenManager
solution: i've set the CPU-taskcycle-time to 20ms and since that modification everthing is fine!
br,
Andy