On 12 June 2018 20:41, quoth Joye Laurent: > And do you have any idea why the command reboot doesn't work in the > case my own application is running?
As noted, the three register writes must be received on three consecutive frames, otherwise the ESC will ignore them. (Also, some implementations of the ESC seem to require a "quiet period" on the network before receiving any other datagram addressed to them, or they abort the reboot; I suspect this is a bug, but it's one we have to live with.) If you have a master application running then there will be all sorts of other activity occurring (notably PDO transfers) and this pretty much guarantees that the above cannot occur, because the current implementation simply injects these one per cycle using the standard background transfer mechanisms. Firmware update (and rebooting) is naturally a disruptive process anyway; you should exit your application (or at least terminate the realtime loop and deactivate the master) and quiesce any other background requests before trying to update firmware or reboot slaves. In principle it might be possible to implement the reboot a little differently and in a way that could rapid-fire the frames and perhaps make it more immune to other activity, but this might still end up disrupting the master application (due to the need for the quiet period) -- and will definitely disrupt it when the slave actually does reboot, since this will take out any devices downstream of it as well. So thus far it hasn't seemed particularly worthwhile pursuing this. _______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
