[etherlab-users] etherlab-users Digest, Vol 104, Issue 1

Tue Feb 2 00:31:12 CET 2016

It is possible to have the master PC connect via standard switch to a standard Ethernet network, one connection of which is the entire EtherCAT slave network.  (It is not possible to have standard Ethernet devices interleaved with EtherCAT devices, at least not without dedicated bridge slaves designed for this purpose.)

This does work, including with Etherlab – I sometimes have a switch between the master and the slaves in order to easily insert another PC running Wireshark to examine the exchanges – but it comes with some caveats.

1.       The EtherCAT messages are broadcasts at the MAC level, so will cause unnecessary traffic on other parts of the network.

2.       Also due to the above, you cannot have two such masters or slave groups on one network, even if each master is intended to talk to different slave sub-networks.  The base EtherCAT protocol does not contain any routing data, so if you need to support this case you’ll have to use a higher-level protocol such as ADS – which as David notes is not supported by Etherlab at present.

3.       If the switch is processing other packets in a store-and-forward manner (which is common) then the non-realtime traffic may adversely affect your realtime performance (especially if there’s a lot of it) and the master may think the packets are getting lost or mismatched.

4.       The most recommended way to operate the Etherlab master is with the customised drivers, which bypass the regular TCP/IP stack.  This means that the master PC won’t be able to send or receive any non-EtherCAT packets anyway.  It’s possible that this limit doesn’t apply when using the generic driver (I haven’t checked), but this comes with lower performance.  (That may not matter to you, depending on your application and the desired cycle times and tolerance to latency or data loss.)

5.       If the first slave is disconnected or powered off, the master will still see this as a link-up network (due to the switch) and will start flooding the syslogs with missing packet errors instead of simply logging a disconnected state.

6.       The first slave will report errors when it receives a non-EtherCAT packet (it will not forward these on to the rest of the EtherCAT network).  Typically you won’t notice this at all unless you are reading the slaves’ error counter registers.

From: David Page
Sent: Tuesday, 2 February 2016 02:39
To: etherlab-users at etherlab.org
Subject: Re: [etherlab-users] etherlab-users Digest, Vol 104, Issue 1

Hi Paul,

The basic story is the EtherCAT slave hardware modifies the Ethernet frame as it passes through each node, and then returns the modified frame back to the host  -- essentially a token passing version of Ethernet. As such, the use of standard hubs or switches will result in a packet storm. The bus design assumes there is exactly one "normal" Ethernet host (at the master). The slave hardware does support a UDP encapsulated mode which is useful for hosts which cannot send and receive raw frames, but the above constraint still applies. 

It is possible with TwinCAT to talk over UDP (EtherCAT ADS protocol) to a remote EtherCAT bridge (e.g. Beckhoff BK9000) which then has another port dedicated to EtherCAT. The Etherlab master does not support ADS, though.

https://infosys.beckhoff.com/english.php?content=../content/1033/tcadscommon/html/tcadscommon_intro.htm <https://infosys.beckhoff.com/english.php?content=../content/1033/tcadscommon/html/tcadscommon_intro.htm&id=> &id=

https://www.beckhoff.com/english.asp?bus_terminal/bk9000_bk9050.htm

    - Dave Page

On Mon, Feb 1, 2016 at 6:00 AM, <etherlab-users-request at etherlab.org <mailto:etherlab-users-request at etherlab.org> > wrote:

Send etherlab-users mailing list submissions to
        etherlab-users at etherlab.org <mailto:etherlab-users at etherlab.org> 

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.etherlab.org/mailman/listinfo/etherlab-users
or, via email, send a message with subject or body 'help' to
        etherlab-users-request at etherlab.org <mailto:etherlab-users-request at etherlab.org> 

You can reach the person managing the list at
        etherlab-users-owner at etherlab.org <mailto:etherlab-users-owner at etherlab.org> 

When replying, please edit your Subject line so it is more specific
than "Re: Contents of etherlab-users digest..."

Today's Topics:

   1. Communicating with Ethercat over TCP/IP network (Paul Mulligan)

----------------------------------------------------------------------

Message: 1
Date: Sun, 31 Jan 2016 14:59:32 +0000 (UTC)
From: Paul Mulligan <mulligan252 at yahoo.ie <mailto:mulligan252 at yahoo.ie> >
To: "etherlab-users at etherlab.org <mailto:etherlab-users at etherlab.org> " <etherlab-users at etherlab.org <mailto:etherlab-users at etherlab.org> >
Subject: [etherlab-users] Communicating with Ethercat over TCP/IP
        network
Message-ID:
        <25812475.4467849.1454252372172.JavaMail.yahoo at mail.yahoo.com <mailto:25812475.4467849.1454252372172.JavaMail.yahoo at mail.yahoo.com> >
Content-Type: text/plain; charset="utf-8"

Hi,
I've read that Ethercat packets can be sent over a network by packing them into UDP datagrams. Is it therefore possible to connect the Ethercat bus with slaves to a network and have the master controller pc not directly connected to the slaves but connected to the same network and hence transfer the Ethercat data to and from the slaves over the network? I assume the timing performance will be worse, but how is this achieved? Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20160131/1b83406c/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
etherlab-users mailing list
etherlab-users at etherlab.org <mailto:etherlab-users at etherlab.org> 
http://lists.etherlab.org/mailman/listinfo/etherlab-users

------------------------------

End of etherlab-users Digest, Vol 104, Issue 1
**********************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20160202/ad8e8b15/attachment-0003.htm>