[etherlab-users] Redundancy support

[Gavin Lambert]

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.