[etherlab-users] Redundancy support

[Dave Page]

On 2015-03-06 06:00, etherlab-users-request at etherlab.org 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/ethercatsystem/html/bt_ecbasics_implementation_dc_ethercatcoupling.htm&id=
http://www.beckhoff.com/english.asp?pc_cards_switches/cu2508.htm

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).

     - Dave

-- 
------------------------------------------------------------------------
David Page, Chief Embedded Architect
Dynamic Systems Inc.
PO Box 1234
Poestenkill, NY 12140
Telephone: +1 (518) 283-5350 | Fax: +1 (518) 283-3160 |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20150319/91cdd77c/attachment-0003.htm>