On 20 March 2015 04:04, quoth Dave Page: > On 2015-03-06 06:00, Gavin Lambert wrote: >> Well, I've fixed that now (it was an incorrect assumption in the EtherCAT >> driver mods), but it hasn't helped the delay measurements. I guess the >> main problem is that the measurement code seems to assume that the receive >> timestamps are all updated from the same packet. But in a redundant >> topology, especially with no network breaks, some of the ports don't >> actually receive packets, or the timestamps within a single slave are >> updated from different packets traversing. So a port might be "open" but >> the timestamp may not have updated or may be from a packet sent at a >> different time from what you're expecting. And the topology calculations >> assume that the packet is always entering from port 0, which isn't always >> true with a redundant setup. (I can understand why -- I've had a think >> about it and it's quite a tricky problem, especially given some of the >> limitations on data available from the slave > > According to Beckhoff: > > Note: for cable redundancy two Ethernet ports are used. However, the > combination of distributed clocks (DC) and cable redundancy is only possible > with device CU2508, see associated device documentation > Ref: http://infosys.beckhoff.com/english.php?content=../content/1033/ethercatsyst em/html/bt_ecbasics_implementation_dc_ethercatcoupling.htm&id= http://www.beckhoff.com/english.asp?pc_cards_switches/cu2508.htm
Sadly this device isn't supported by EtherLab, AFAIK. It's not quite true that this is the only way (though I don't dispute that it's probably the best way) -- you can trick an EK1122 into doing an adequate job (with the below patches). Although it's actually so good at it that the EtherLab master doesn't notice when the network breaks, which is great for cyclic data but can be problematic for some things. It does unfortunately still ruin the delay measurements and DC synchrony, though. > I could see how it would be possible to make DC work with master software > only, but some considerable delay would be involved to identify the new > topology. (Process data, on the other hand can just be sent out both master > ports with zeroed input PDOs and then bitwise ORed on receipt). If you have a look at the devel list, I've posted some patches that improve things a bit (at least detecting which timestamps are unreliable, so that the delay calculations are only somewhat wrong instead of being completely silly). Obviously you're not going to get "real" DC synchrony in a broken network, but sometimes all you really want are the local sync output timers, and actual synchronisation is less important. Where it's slightly annoying is that even in a non-broken network it's not possible to correctly measure delays unless you forcibly close the redundant link -- and doing that is fatal to communications if it turns out that the network is actually broken. And without foreknowledge of the network topology it can be difficult to detect whether the network is broken or not (for example, it's *not* abnormal to have some devices responding only on the backup link even when the network isn't broken). As it stands, if using redundant master ports then even after my patches if some devices are only on the backup link then they won't be DC synchronised, because the EtherLab master only keeps one reference clock (instead of one per half network) and doesn't forward the slave sync datagram between main & backup links, so they'll gradually drift. But even if it did so it'd be vulnerable to master software jitter so it's just another case of reducing synchrony. But I'm not sure if it's possible to properly enumerate a partially-reversed network at all without either having foreknowledge of the expected topology (which is how TwinCAT does it, I suspect) or selectively closing ports to disambiguate the scans (which means it can't be done without disrupting communication). And the latter can be dangerous if the master guesses wrong. _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users