Hi, I've recently been trying to test a bunch of unusual configurations to see how things behave. One of these is a configuration where slaves are present on the network, but none have been added to any domains. (It seems like a reasonable interim bring-up state.)
In this case, if I call ecrt_master_activate and run a realtime loop (dispatching internal packets but not actually processing any domains) then the first slave on the network will log a "Sync manager watchdog" error frequently (about twice per second, at least with my test setup), because the master keeps putting it into OP but is not actually sending any output data to it. This appears to be a collision between automatically selecting the first DC-capable slave on the network as the reference clock and ec_master_request_op requiring the reference slave to be brought to OP even if it's not configured. Is this expected behaviour? In particular, 1. Why does the reference clock need to be forced to OP? DC sync registers etc still work perfectly fine in any state, AFAIK. I suppose there might be something special needed for some special kinds of clocks (eg. one that has external syncing) but presumably the master app would config and/or select them explicitly in that case. 2. Why does the auto-selection select a slave that is not configured? Since unconfigured devices may not be able to go to OP at all, this seems like a conflict with the prior requirement. Shouldn't it pick the first present *and configured* slave that supports DC? 3. Why does it want to have a reference clock at all in a network with no configured slaves, even when slaves are present? Regards, Gavin Lambert _______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
