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...
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...
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 (gess 1,5*500ms) -> so IMHO increasing the errorthreshold/hb-timeout...
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!?!...