<div dir="ltr">ET1100 Section I.3 Frame Processing:<div><br><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>It is not possible to use unmanaged switches between these ESCs or between master and the first<br></div></div><div><div>slave, because source and destination MAC addresses are not evaluated or exchanged by the ESCs.</div></div><div><div>Only the source MAC address is modified when using the default settings, so outgoing and incoming</div></div><div><div>frames can be distinguished by the master.</div></div><div><div>NOTE: Attaching an ESC directly to an office network will result in network flooding, since the ESC will reflect any</div></div><div><div>frame – especially broadcast frames – back into the network (broadcast storm</div></div><div><br></div></blockquote>If ESC DL Control register bit 0 is clear, then all frames are forwarded. </div><div><br></div><div><div>$ sudo ethercat -p0 reg_read 0x100 4</div><div>0x00 0x00 0x07 0x00</div></div><div><br></div><div>On my hardware bit 0 is clear after configuration by the etherlab master.</div><div><br></div><div>Clearly under certain configurations, it is possible to use an unmanaged switch. It is also quite possible to use a managed switch to perform some layer 2 routing. For a beginner, it is probably best to just add another ethernet adapter.</div><div><br></div><div>    Best regards - Dave</div><div><br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 6:31 PM, Gavin Lambert <span dir="ltr"><<a href="mailto:gavinl@compacsort.com" target="_blank">gavinl@compacsort.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-NZ" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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 <b>not</b> possible to have standard Ethernet devices interleaved with EtherCAT devices, at least not without dedicated bridge slaves designed for this purpose.)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><span>1.<span style="font:7.0pt "Times New Roman"">       </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The EtherCAT messages are broadcasts at the MAC level, so will cause unnecessary traffic on other parts of the network.<u></u><u></u></span></p><p><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><span>2.<span style="font:7.0pt "Times New Roman"">       </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.<u></u><u></u></span></p><p><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><span>3.<span style="font:7.0pt "Times New Roman"">       </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.<u></u><u></u></span></p><p><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><span>4.<span style="font:7.0pt "Times New Roman"">       </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.)<u></u><u></u></span></p><p><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><span>5.<span style="font:7.0pt "Times New Roman"">       </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.<u></u><u></u></span></p><p><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><span>6.<span style="font:7.0pt "Times New Roman"">       </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> David Page<br><b>Sent:</b> Tuesday, 2 February 2016 02:39<br><b>To:</b> <a href="mailto:etherlab-users@etherlab.org" target="_blank">etherlab-users@etherlab.org</a><br><b>Subject:</b> Re: [etherlab-users] etherlab-users Digest, Vol 104, Issue 1<u></u><u></u></span></p></div></div><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">Hi Paul,<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">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. <u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><a href="https://infosys.beckhoff.com/english.php?content=../content/1033/tcadscommon/html/tcadscommon_intro.htm&id=" target="_blank">https://infosys.beckhoff.com/english.php?content=../content/1033/tcadscommon/html/tcadscommon_intro.htm&id=</a><u></u><u></u></p></div><div><p class="MsoNormal"><a href="https://www.beckhoff.com/english.asp?bus_terminal/bk9000_bk9050.htm" target="_blank">https://www.beckhoff.com/english.asp?bus_terminal/bk9000_bk9050.htm</a><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">    - Dave Page<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Mon, Feb 1, 2016 at 6:00 AM, <<a href="mailto:etherlab-users-request@etherlab.org" target="_blank">etherlab-users-request@etherlab.org</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal">Send etherlab-users mailing list submissions to<br>        <a href="mailto:etherlab-users@etherlab.org" target="_blank">etherlab-users@etherlab.org</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br>        <a href="http://lists.etherlab.org/mailman/listinfo/etherlab-users" target="_blank">http://lists.etherlab.org/mailman/listinfo/etherlab-users</a><br>or, via email, send a message with subject or body 'help' to<br>        <a href="mailto:etherlab-users-request@etherlab.org" target="_blank">etherlab-users-request@etherlab.org</a><br><br>You can reach the person managing the list at<br>        <a href="mailto:etherlab-users-owner@etherlab.org" target="_blank">etherlab-users-owner@etherlab.org</a><br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of etherlab-users digest..."<br><br><br>Today's Topics:<br><br>   1. Communicating with Ethercat over TCP/IP network (Paul Mulligan)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Sun, 31 Jan 2016 14:59:32 +0000 (UTC)<br>From: Paul Mulligan <<a href="mailto:mulligan252@yahoo.ie" target="_blank">mulligan252@yahoo.ie</a>><br>To: "<a href="mailto:etherlab-users@etherlab.org" target="_blank">etherlab-users@etherlab.org</a>" <<a href="mailto:etherlab-users@etherlab.org" target="_blank">etherlab-users@etherlab.org</a>><br>Subject: [etherlab-users] Communicating with Ethercat over TCP/IP<br>        network<br>Message-ID:<br>        <<a href="mailto:25812475.4467849.1454252372172.JavaMail.yahoo@mail.yahoo.com" target="_blank">25812475.4467849.1454252372172.JavaMail.yahoo@mail.yahoo.com</a>><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi,<br>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<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <<a href="http://lists.etherlab.org/pipermail/etherlab-users/attachments/20160131/1b83406c/attachment-0001.html" target="_blank">http://lists.etherlab.org/pipermail/etherlab-users/attachments/20160131/1b83406c/attachment-0001.html</a>><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>etherlab-users mailing list<br><a href="mailto:etherlab-users@etherlab.org" target="_blank">etherlab-users@etherlab.org</a><br><a href="http://lists.etherlab.org/mailman/listinfo/etherlab-users" target="_blank">http://lists.etherlab.org/mailman/listinfo/etherlab-users</a><br><br><br>------------------------------<br><br>End of etherlab-users Digest, Vol 104, Issue 1<br>**********************************************<u></u><u></u></p></blockquote></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div></div></blockquote></div><br></div>