2014年6月29日 星期日

EtherCAT Master project

2014/07/10  update!
http://etherlab.org/en/ethercat/index.php

See the list of features for the IgH EtherCAT® Master.

There is also a table of supported Ethernet hardware, and a list of Frequently Asked Questions available.
License
All the source code available through IgH is licensed under the GPLv2 license.
Notice

The license above concerns the source code only. Using the EtherCAT technology and brand is only permitted in compliance with the industrial property and similar rights of Beckhoff Automation GmbH.

Repository Access
The Mercurial repository of the EtherCAT master is hosted on SourceForge. The following command can be used to clone the repository in order to get the latest revisions:hg clone http://hg.code.sf.net/p/etherlabmaster/code ethercat-hg

Please note that the default branch is selected after cloning, which contains the development version. For changing into another branch (for example stable-1.5) please use the following command:hg update stable-1.5

The repository can also be browsed online.
File Downloads
ReleaseDate
Version 1.5.2 (current)
Source code [tar.bz2] [sig] [md5]
Documentation [pdf]
Features [HTML] 2013-02-12
Version 1.5.1
Source code [tar.bz2] [sig] [md5]
Documentation [pdf]
Features [HTML] 2012-02-07
Version 1.5.0
Source code [tar.bz2] [sig] [md5]
Documentation [pdf]
Features [HTML] 2012-01-10
Version 1.4.0
Source code [tar.bz2] [sig] [md5]
Documentation [pdf]
Features [HTML] 2008-12-29
Version 1.4.0-rc3
Source code [tar.bz2] [sig] [md5]
Documentation [pdf]
Features [HTML] 2008-10-02
Version 1.4.0-rc2
Source code [tar.bz2] [sig] [md5]
Documentation [pdf]
Features [HTML] 2008-08-27
Version 1.4.0-rc1
Source code [tar.bz2] [sig] [md5]
Features [HTML] 2008-08-01
Version 1.3.2
Source code [tar.bz2] [sig] [md5]
Features [HTML] 2007-10-04
Version 1.3.1
Source code [tar.bz2] [sig] [md5]
Features [HTML] 2007-09-17
Version 1.3.0
Source code [tar.bz2] [sig] [md5]
Features [HTML] 2007-08-10
Version 1.2.0
Source code [tar.bz2] [sig] [md5] 2007-02-13
Version 1.1.1
Source code [tar.bz2] [sig] [md5]
Documentation [pdf]
HTML Source code documentation [tar.bz2] [online] 2006-11-07
Version 1.1, revision 535
Source code [tar.bz2]
Documentation [pdf]
HTML source code documentation [zip] [tar.bz2] [online]
Function reference [pdf] 2006-09-01
Version 1.0, revision 492
Source code [tar.bz2]
HTML source code documentation [zip] [tar.bz2] [online]
Function reference [pdf] 2006-08-02

Integrity Check

EtherLab-Software is signed with one or more of the following keys:pub 1024D/CCA047CC 2007-12-18 [expires: 2012-12-16] Key fingerprint = 0081 4005 FE9F 73FF 4BDA A409 0011 4E20 CCA0 47CC uid Dipl.-Ing. (FH) Florian Pose (Ingenieurgemeinschaft IgH GmbH) <fp@igh-essen.com> sub 2048g/7595606A 2007-12-18 [expires: 2012-12-16]
pub 1024D/EBDAAF9D 2004-12-25 Key fingerprint = A652 E009 D3FA C91D 566F 99D6 4D20 1D59 EBDA AF9D uid Florian Pose <florian@keenkiwi.de> uid Dipl.-Ing. (FH) Florian Pose (Ingenieurgemeinschaft IgH) <fp@igh-essen.com> sub 2048g/E64BDA6F 2004-12-25


Supported Ethernet Hardware

This page shall give an overview of the Ethernet hardware, that is natively supported by the EtherCAT master. The listed Ethernet drivers come with the EtherCAT master sources and are EtherCAT-enabled versions of their standard-kernel-counterparts, and therefore are able to drive the same set of hardware.

Generic Ethernet Driver

Since version 1.5, there is a generic Ethernet driver among the native ones, that spans all Ethernet devices supported by the Linux kernel. Although it is not usable with realtime patches like RTAI (because it uses the lower network stack layers), it runs perfectly with realtime preemption.

Native Ethernet Drivers

These natively supported drivers and their corresponding hardware are mentioned below:
  • 8139too - RealTek 8139C (or compatible) Fast-Ethernet chipsets.
  • e1000 - Intel PRO/1000 Gigabit-Ethernet chipsets (PCI).
  • e100 - Intel PRO/100 Fast-Ethernet chipsets.
  • r8169 - RealTek 8169/8168/8101 Gigabit-Ethernet chipsets.
  • e1000e - Intel PRO/1000 Gigabit-Ethernet chipsets (PCI Express).
The below tables show for each master version, which drivers are available for which kernel version.

Legend

  • X: The driver is available.
  • -: The driver was not (yet) patched for that kernel version.

Development Branch

8139tooe1000e100r8169e1000e
3.2---XX
3.0-XX--
2.6.37XXXXX
2.6.36X--X-
2.6.35XXXXX
2.6.34X---X
2.6.33XXXXX
2.6.32XXXXX
2.6.31XXXX-
2.6.29XXXX-
2.6.28XXXX-
2.6.27XXXX-
2.6.26XXX--
2.6.25X----
2.6.24XXXX-
2.6.23X----
2.6.22XX---
2.6.20-XX--
2.6.19X----
2.6.18XX---
2.6.17X----
2.6.13XX---

Version 1.5.2

8139tooe1000e100r8169e1000e
3.4XXXXX
3.2X--XX
3.0XXX--
2.6.37XXXXX
2.6.36X--X-
2.6.35XXXXX
2.6.34X---X
2.6.33XXXXX
2.6.32XXXXX
2.6.31XXXX-
2.6.29XXXX-
2.6.28XXXX-
2.6.27XXXX-
2.6.26XXX--
2.6.25X----
2.6.24XXXX-
2.6.23X----
2.6.22XX---
2.6.20-XX--
2.6.19X----
2.6.18XX---
2.6.17X----
2.6.13XX---

Version 1.5.1

8139tooe1000e100r8169e1000e
2.6.37XXXXX
2.6.36X----
2.6.35XXXXX
2.6.34X---X
2.6.33XXXXX
2.6.32XXXXX
2.6.31XXXX-
2.6.29XXXX-
2.6.28XXXX-
2.6.27XXXX-
2.6.26XXX--
2.6.25X----
2.6.24XXXX-
2.6.23X----
2.6.22XX---
2.6.20-XX--
2.6.19X----
2.6.18XX---
2.6.17X----
2.6.13XX---

Version 1.5

8139tooe1000e100r8169e1000e
2.6.37XXXXX
2.6.36X----
2.6.35X----
2.6.34X---X
2.6.33XXXXX
2.6.32XXXXX
2.6.31XXXX-
2.6.29XXXX-
2.6.28XXXX-
2.6.27XXXX-
2.6.26XXX--
2.6.25X----
2.6.24XXXX-
2.6.23X----
2.6.22XX---
2.6.20-XX--
2.6.19X----
2.6.18XX---
2.6.17X----
2.6.13XX---

Version 1.4

8139tooe1000r8169
2.6.28--X
2.6.24XXX
2.6.23X--
2.6.22XX-
2.6.20-X-
2.6.19X--
2.6.18XX-
2.6.17X--
2.6.13XX-

Version 1.3

8139tooe1000e100
2.6.22-X-
2.6.20-XX
2.6.19X--
2.6.18XX-
2.6.17X--
2.6.13XX-





Ethercat Q & A
Q: I am completely new for ethercat.
I am completely new for ethercat. And I am looking for a good starting point to study ethercat master. I found that there is greate open source implementation called SOEM. (https://developer.berlios.de/projects/soem/) But without any background of ethercat, It is really hard to understand the code.

Could anybody help me to find the way studying ethercat master?

Answer
To start you need to understand the technology before you can dive into the master. I'd recommend the following three resources.
  • EtherCAT Technology (Section I)
    • This is an overview of the technology and definitely where you want to start.
  • EtherCAT Registers (Section II)
    • This is a dry read, but a good reference to understand the different registers that are used to communicate between an EtherCAT master and slave.
  • ET1100 Hardware Data Sheet
    • Even drier, but this is a datasheet for a common ASIC for building an EtherCAT slave. It can help you understand even more detail about the communication between an EtherCAT master and slave.

To properly implement an EtherCAT master is no easy task and requires a lot of reading. There is more documentation available but it requires a membership to the EtherCAT Technology Group. That's where you can get access to more technical information.

Another EtherCAT master open source project, that I'm familiar with, is IgH

Q: About IgH ethercat master

I start working on EtherCAT, I have to control ethercat slave using Ubuntu as EtherCAT master. From google I came to know that I can use IgH EtherCAT master in ubuntu for my project but I am not getting how can I use IgH master , some buddy please help me.

Answer
Please read the doc file with the version your going to work, ethercat doc pdf file which is there on website : http://www.etherlab.org/en/ethercat/index.php
then please check with your study which real-time system you what to use for linux, I'm currently using LinuxCNC iso installed on my system, please verify the ethernet card on the system too, its very important and check it on etherlab site that its supported or not yet, as of the latest version of ethercat master from etherlab is having an generic driver too, but you need to check that for sure.
once you get Linux real-time installed, go for the installation of ethercat as mention in docs (for which the link is given above) follow all the steps properly and then check its status using demsg command from linux. I hope this helps you, please let know if you find some issues with it.

Q:How does EtherCAT support different network topologies?

How does EtherCAT support different network topologies?
Assume a pure EtherCAT network without any standard ethernet switches, hubs, etc... to complicate things, and with one master and multiple slaves.
Some sources describe it as only supporting ring topologies (i.e. Wikipedia), and this makes sense given the theory of operation, but the EtherCAT website says it supports other topologies as well.
100BaseTX ethernet cables contains two half-duplex links, one in each direction; is it true that when viewed as a graph of half-duplex links, EtherCAT is always a ring bus, but when viewed as a graph of physical ethernet cables, the graph can be almost arbitrary?
Answer:
no Answer

Q: If UDP packets are on the wire, am I guaranteed to get them at the application layer?

Firstly I appreciate the UDP is not a reliable protocol, and I am not guaranteed to receive packets across a network.
However, if the packet does reach my machine, am I guaranteed to receive it at the application level, or can the network stack throw it away with impunity?
The reason I ask is that I seem to be missing packets occasionally, even though I know they're on the wire (simple EtherCAT bus, so packets always loop back).
Answer:
No, there is no guarantee the packets will reach your application even if they reach your machine.
The kernel's UDP receive queue is finite, and if the packets arrive faster than your application can handle them, the queue will fill up and some of the packets will be dropped.
You can increase the size of the receive buffer (see this question), but you cannot make it unlimited.

Q:Undefined reference clock_gettime

I do not know how to get clock_gettime(). I used -irt option. But i get error. Other problems? Please help me.
root@c405:/home/c405/workspace/rpy/Beremiz_120730/EtherLAB/tool# make
/bin/sh ../libtool --tag=CXX   --mode=link g++ -I../include -I../master -Wall -DREV=`if test -s ../revision; then cat ../revision; else hg id -i .. 2>/dev/null || echo "unknown"; fi` -fno-strict-aliasing -g -O2    -o ethercat soe_errors.o ethercat-Command.o ethercat-CommandAlias.o ethercat-CommandCStruct.o ethercat-CommandConfig.o ethercat-CommandData.o ethercat-CommandDebug.o ethercat-CommandDomains.o ethercat-CommandDownload.o ethercat-CommandFoeRead.o ethercat-CommandFoeWrite.o ethercat-CommandGraph.o ethercat-CommandMaster.o ethercat-CommandPdos.o ethercat-CommandRegRead.o ethercat-CommandRegWrite.o ethercat-CommandRescan.o ethercat-CommandSdos.o ethercat-CommandSiiRead.o ethercat-CommandSiiWrite.o ethercat-CommandSlaves.o ethercat-CommandSoeRead.o ethercat-CommandSoeWrite.o ethercat-CommandStates.o ethercat-CommandUpload.o ethercat-CommandVersion.o ethercat-CommandXml.o ethercat-DataTypeHandler.o ethercat-FoeCommand.o ethercat-MasterDevice.o ethercat-NumberListParser.o ethercat-SdoCommand.o ethercat-SoeCommand.o ethercat-main.o ethercat-sii_crc.o ethercat-CommandEoe.o  -irt 
libtool: link: g++ -I../include -I../master -Wall -DREV=unknown -fno-strict-aliasing -g -O2 -o ethercat soe_errors.o ethercat-Command.o ethercat-CommandAlias.o ethercat-CommandCStruct.o ethercat-CommandConfig.o ethercat-CommandData.o ethercat-CommandDebug.o ethercat-CommandDomains.o ethercat-CommandDownload.o ethercat-CommandFoeRead.o ethercat-CommandFoeWrite.o ethercat-CommandGraph.o ethercat-CommandMaster.o ethercat-CommandPdos.o ethercat-CommandRegRead.o ethercat-CommandRegWrite.o ethercat-CommandRescan.o ethercat-CommandSdos.o ethercat-CommandSiiRead.o ethercat-CommandSiiWrite.o ethercat-CommandSlaves.o ethercat-CommandSoeRead.o ethercat-CommandSoeWrite.o ethercat-CommandStates.o ethercat-CommandUpload.o ethercat-CommandVersion.o ethercat-CommandXml.o ethercat-DataTypeHandler.o ethercat-FoeCommand.o ethercat-MasterDevice.o ethercat-NumberListParser.o ethercat-SdoCommand.o ethercat-SoeCommand.o ethercat-main.o ethercat-sii_crc.o ethercat-CommandEoe.o -irt 
ethercat-CommandSlaves.o: In function `CommandSlaves::listSlaves(MasterDevice&, std::list<ec_ioctl_slave_t, std::allocator<ec_ioctl_slave_t> > const&, bool)':
/home/c405/workspace/rpy/Beremiz_120730/EtherLAB/tool/CommandSlaves.cpp:176: undefined reference to `clock_gettime'
collect2: ld returned 1 exit status
make: *** [ethercat] 오류 1
root@c405:/home/c405/workspace/rpy/Beremiz_120730/EtherLAB/tool#
Answer:
Use -lrt instead of -irt. Mispelled?

I'm working on an Ethercat master written Go. The underlying library is athttp://github.com/distributed/ecat and contains one link level driver, using UDP and multicast. I'm having trouble to get this link level driver to work consistently across multiple platforms (OS X, Windows, Linux) and different networking configurations.
For those not familiar with Ethercat, here's how it works. Ethercat is an industrial bus system based on Ethernet. There's one bus master and potentially many slaves, which are connected into a logical ring. The master can be built from off-the-shelf hardware, i.e. with normal Ethernet interface cards. The master sends a packet on its Ethernet interface, the slaves modify the packet on the fly and after passing through all the slaves, the master receives the packet on the same network interface that sent it. Depending on the number of slaves, the network interface might start to receive the packet while it is still transmitting the very same packet. There are two possible formats for Ethercat frames. The first is an Ethernet packet with a special ethertype. The second is a UDP packet destined for port 0x88a4.
Depending on the commands contained in an Ethernet packet, the slaves may or may not modify the packet's Ethercat data. Apart from changing Ethercat data, the only thing about the packet that is changed is that bit 1 of the Ethernet destination address is set to 1. The IP header of the packet is not touched by the Ethercat slaves.
My code works as follows. I join a multicast group, say 239.255.65.10 on interface xyz, where I connected my Ethercat slaves. To exchange data with the bus, I send a packet, let's call it pA on this interface to 239.255.65.10. The OS fills in the source address, say the IP address 192.168.5.2 of interface xyz. After the packet passed through the bus and was possibly altered, it's now packet pB. The IP header still has a source of 192.168.5.2 and a destination of 239.255.65.10. Depending on the host's networking settings, this packet might or might not reach my application. In the cases where it does not reach my application, say when rp_filter is set, on Linux, packet pB is rejected because it looks like it originated from my machine, but we shouldn't be receiving our own packets over the network.
What steps can I take to reliably receive the processed packet pB? Please note that I'm not speaking about loopback - loopback is about receiving packet pA, my question is about receiving pB.
Answer:
Well, quick googling for multicast+rp_filter turns up that setting rp_filter to 1 reliably disables receiving multicast traffic in your case, so while I don't have a real answer, it appears that it could be "no, you have to warn the user in the README file". 

Q: Sending UDP Packets from Wireshark / tshark

I am working with a "real time" data analysis toolchain which is separated into two parts. The first part fetches the data to be analyzed, packs it into a UDP packet and sends it to another host. The second part, running on the aforementioned host, receives the UDP packets and performs analysis on the received packets. By "real time" I mean that the output of the analysis toolchain should appear live to a human user, thus latencies of up to 100 ms are acceptable.
I am looking into making a new data source available to the receiving part. The data that I am looking for are being transferred on an Ethercat bus, which I can sniff. Wireshark/tshark have a dissector for Ethercat packets. With that said, it's really simple to get at the data in a script running within Wireshark/tshark. Since I have little control over the second part of the analysis, I cannot readily modify the second part to sniff Ethercat frames via pcap or somesuch.
Is it possible to send UDP packets from a script running in Wireshark/tshark?
Answer:
Wireshark's Lua doesn't have a way to do that available out-of-the-box, but it's stock Lua so you can write a wireshark Lua script which itself can import (i.e., use require) any other Lua script or compiled Lua dll/so library. So, for example, you could use the LuaSocket library to send packets from within your wireshark Lua script.
Note that there is no event loop available to Wireshark Lua scripts, so receiving packets via LuaSocket isn't going to work, afaik. But since you're talking about sending over UDP, and sending only when the Wireshark Lua script will get invoked (i.e., because you'd do the send() call inside a tap or dissector), I think it should work. If it does/doesn't please post back, because this question comes up now and then and it would be good to know.

Q:How to send Ethernet-Frames in Java without TCP/IP Stack

My Java application should control an external device (EtherCAT Bus technology) directly connected to the network interface of my computer(Ubuntu and Windows). No other network devices are connected. The communication has do be done on Standard IEEE 802.3 Ethernet Frames without IP stack.
Example for sending data:
int etherType =  0x88A4;  // the EtherType registered by IEEE
byte[] macBroadcast = new byte[] {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};
byte[] macSource = new byte[] ... ;  // MAC Address of my network interface card
byte[] buffer = ... // the data to send

device.write(macSource, macBroadcast, etherType, buffer);
I tried JNetPcap, which uses the pcap native library. The given API was fine, but there were multithreading issues on heavy load, which forced me to give up.
netty.io was also a candidate. I am not sure, but a TCP/IP stack is mandatory. Am I right?
Are there other ideas to communicate with low level Ethernet Frames? I would prefer a pure java library like netty.io, if one exists.
Of course JNA/JNI is an option, too. But I don't want to write C code.
Other alternatives?
Answer:
These are the options I was able to find:
I've also seen comments to the effect that jnetpcap is supposed to be thread-safe but that in practice it is not; i.e. it is buggy when used with multiple threads.

Q: Raspberry Pi spidev.h SPI Communication

I try to establish a spi communication from RPi (Master) to an EtherCAT Device (Slave).
The transfer of data got a scheme.
I have to transfer 2 bytes which address registers and the following bytes transfer data till a chip select terminates the communication.
This is my created attempt. With cs_change, i can tell my spi communication to deselect Chip Select before the next transfer starts.
char transfer(UINT8 data, char last)
{
char last_transfer = last;
int ret;
uint8_t tx[] = { data };
uint8_t rx[ARRAY_SIZE(tx)] = { };

struct spi_ioc_transfer tr = {
        .tx_buf = (unsigned long)tx,
        .rx_buf = (unsigned long)rx,
        .len = ARRAY_SIZE(tx),
        .delay_usecs = delay,
        .speed_hz = speed,
        .bits_per_word = bits,
        .cs_change = 0,
    };

if (last_transfer)
    tr.cs_change = 1;

ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr);
if (ret < 1)
    printf("can't send spi message");

return rx[tr.len-1];
}
First problem: I think it is too late to deselect Chip Select first at new transfer. So my first question: Is there another way to control my Chip Select signal, maybe another library i can use?!
Second problem: I want to read from spi without writing on it, how can i realise that ( with a simple read(fd...) ?!)
I hope you guys can support me :)
Answer1:
Now this is spidev_test.c application you are referring to. The implementation seems to work as slave SPI device would be deselected after your last transfer. It stays selected until after the last transfer in a message. Each SPI device is deselected when it's not in active use, allowing other drivers to talk to other devices as may be your SPI bus is shared among other slave SPI devices. And moreover you are going for full-duplex. Standard read() operation is obviously only half-duplex. So whenever your SPI slave device wants to send data to the SPI controller(Master), then it must have some interrupt mechanism so that your driver/app can set the SPI controller to "SPI_IOC_RD_MODE" and can make "SPI_IOC_MESSAGE" providing only rx_buf OR you can go for only simple read() operation as the transfer would be half_duplex after setting the SPI controller to read mode. -Sumeet

Answer2:
You can use SPI_NO_CS mode and toggle the CS pins as GPIO using the wiringPi library... (fromhttp://wiringpi.com/ )

Q:Portable hard real-time C or C++ raw Ethernet protocol library

I am trying to create a hobbyist portable robotics library (Windows and Linux) that has hard real-time capabilities. It should be able to connect over standard Ethernet to a microcontroller, upload firmware to that device, connect to other devices over a fieldbus, and upload firmware to those other microcontrollers that run dedicated controllers. NICs will be those supported by RTnet if hard real-time is desired. I will want typical servo rates of at least 1 kHz but preferrably 2 kHz or higher. It will be running a completely custom protocol (not TCP or UDP over IP) so that the overhead is minimal and the high-speed fieldbus can be saturated while not receiving or transmitting frames. The payload in the Ethernet frame can then be interpreted or sent to connected devices.
1) I prefer to keep the protocol in C++ but know that using the "new" keyword won't work for real-time programming. What other limitations will I run into if I choose to use the C++ language rather than converting the project into C? Do people recommend books or websites that teach how to utilize C++ and meet hard real-time deadlines? I beleive it's possible and I hope to be able to go ahead with using C++ because the Orocos project uses real-time C++. I would prefer not to use C code.
2) In order to keep the portable protocol library general purpose how should the program handle the protocol running simultaneously on both a non-realtime Ethernet adapter and say an RTnet Ethernet adapter?
A specific question that I have would be a question about say a portable Mutex class that can use either a boost or a Xenomai mutex.
Solution 1 to problem 2 could be the following: If the application has also been compiled with the Xenomai libraries then a mutex could be constructed with a boolean flag to say which methods (either boost or Xenomai) would be wrapped at runtime for lock and unlock. It could contain the boost mutex and a Xenomai mutex if the library was compiled for Xenomai. I don't like this solution because if the project is compiled for Xenomai then it will contain private variables of a mutex for boost and Xenomai, which seems like a less elegant way then having just the mutex that one needs.
Solution 2 to problem 2 could be the following: Write 2 different derived classes from an abstract class of pure virtual interface methods to the mutex, one for boost and one for Xenomai. I like this way better but then telling which class to use at run-time is cumbersome. I'd maybe have to have pools of a boost and Xenomai mutexes. Is this how most hard real-time C++ programs address the issue?
I have this issue coming up with more than just a mutex but would like to receive feedback since I don't want to replicate bad design patterns from the start.
3) I believe TwinCAT from Beckoff runs EtherCAT in real-time under Windows 7. Is there anything that will be coming out that would not be out of reach of the hobbyist that supports at least one NIC with hard real-time under Windows 7 or later? Maybe there is an open source Hypervisor project.
4) Also, how do people load the system so that their quad-core computers are using 100 % of each of the cores so that they can tell if their system is not running in hard real-time?
  1. You should split this up into small, concise questions. This is too much to digest. – Jonathon Reinhart Nov 18 '12 at 2:31
  2. What layer of the network stack specifies collision detection and avoidance? I'm having a hard time seeing how a system employing the usual random-wait CD/CA can make hard realtime guarantees. – dmckee Nov 18 '12 at 2:36
  3. To do anything "hard real time" you need "hard real-time" OS. Neither Windows or Linux is in that category.– Nikolai N Fetissov Nov 18 '12 at 3:44
    • There will only be collisions if there is a new Ethernet device that comes online and makes the system non-realtime for some time. The protocol chosen avoids any other collisions. There doesn't need to be more than one Ethernet device as I don't expect most hobbyists to need more than one Ethernet microcontroller attached that gives them a high speed fieldbus. Complex robots needing more than one high speed fieldbus off of a single Ethernet port would need to accept a non-realtime glitch with my design but I don't see an easy workaround. – Edward Nov 18 '12 at 3:46
    • @dcmkee: CD/CA are pretty much defunct with the advent of switches and full-duplex links. Collisions only happen when you use non-switching hubs. Instead, you need to worry about queue depth in the switch, but that's a much more tractable problem
Answer1:

One detail : if you want a 1khz refresh cycle for servos, why are you using hard real-time ? Soft real-time (ie. run as root, but pure userspace but set scheduler policy to FIFO levels for that process, lock everything into memory, disable swapspace ...) and you'll easily get 1khz out of it without missing a single message in an entire year of running.
At this point, just use a raw socket for your ethernet protocol and call it a day.
As to the unrelated question ethernet CD/CA are implemented in hardware these days. Just ignore them.
This was helpful to get started with soft real-time. It generally works with < 100 uS latencies while running background processes. Hard real-time is working now and Xenomai with RTnet do seem to have an upper limit of about 50 uS without much tweaking of kernel settings.
SOEM is a C library implementing an EtherCAT (Ethernet for Control Automation Technology) Master. The homepage of the project is http://soem.berlios.de/.
It's primary target system is Linux, all examples are written for it. But as all applications are different, SOEM tries to not impose any design architecture. It can be used in generic user mode, PREEMPT_RT or Xenomai. Also converting it to other targets is relativly simple. For detailed information about EtherCAT vistit the ETG (EtherCAT technology group) site, see the links section below.
Here, at IOC Robotic's Lab, we have done (with some foreign help) some modifications of the SOEM library to improve it. Basically we have created a migration to CMake as build tool and made some modification to run it under rtnet/xenomaihttp://www.rtnet.org.

CMake improvements

With CMake now you can:
  • Create a static and dynamic library of soem.
  • Install it (default /usr/local) or whenever you want.
  • Build or not the examples.
  • Create the static and dynamic version patched to run under rtnet
  • Build the rtnet version of the examples.

Download and install

We have use git and you can download and build as usual:
git clone http://sir.upc.edu/projects/soem/soem.git soem.git
cd soem.git
mkdir build
cd build
cmake ../
make
make install
[$[Get Code]]
Edit the CMake options to fit your needs.

Ethercat Information

We had a student that elaborated some documentation of Ethercat. This documentation could be found here.Development.Ethercat

others ethercat master LINK:


This is work in progress

Realtime options in Linux

Generic stock Linux kernel hasn't realtime capabilities as the kernel task scheduler can preempt any user task at any instant if other tasks with higher priority need the use of the processor. For this reason several solutions providing realtime capabilities to Linux have been proposed, being the following the more widely known:
RT-Preempt patch for the Linux Kernel
To be done
RT-Linux
RTLinux is a hard realtime RTOS microkernel that runs the entire Linux operating system as a fully preemptive process. Theoretically is free software. However, a patent covering this technology was filed, and the unclear legal status surrounding this project is preventing its use within the free software projects.
RTAI
Based on a different mechanism than RT-Linux to avoid the latter patented technology, this project makes use of the Aedos interrup pipeline wich introduces a hardware abstraction layer allowing deterministic handling of interrupts prior to sending them to the linux interrupt handling routines.
Xenomai
A fork of RTAI due to developer differences, its developing seems to be more active nowadays. This is the solution we've chosen.

Enabling Xenomai extensions into the Linux kernel

To be done

Realtime Networking

Networking, specially ethernet networking, poses great challenges to a realtime environment. With Ethernet, the communications are not deterministic because of the collision which can occur between several host on a network with a hub, or because of the unknown latency in the case of the switch. These collisions are unavoidable as they constitute the mechanism the network nodes use to gain access to the communication media shared between al network devices. This mechanism is known as CSMA/CD (Carrier Sense Multiple Access/Collision Detection).
To work around this, some slight modifications of the original ethernet standard have been proposed, being RTnet one of the most interestings at present. RTnet is a protocol stack which run between the Ethernet layer and the application layer (or IP layer). It aims, through the use of time intervals (time-slots), is to make deterministic communication, by substituting the CSMA/CD media access method by a TDMA (time division multiple access) strategy and prevent buffering packet in the network. RTnet is a software developed to run on Linux kernel with RTAI or Xenomai real-time extension. It exploits the real time kernel extension to ensure the determinism on the communication stack. In this aim, all the instructions related to this protocol makes use real time kernel functions rather than those of Linux, which bound latencies to the execution times and latencies of interruptions which provide deterministic's communication.
So, to be clear, RTnet achieves realtime networking by addressing two issues simultaneously:
  1. First, it works inside a realtime operating system (like Linux with Xenomai extensions) to ensure deterministic software processing of the incoming/outgoing data packets.
  2. Second, it uses a TDMA media access mechanism to avoid packet collisions into the physical media, which would lead to unpredictable communication delays. To achieve this an additional protocol layer called RTmac controls the media access. A dedicated Ethernet segment is required to guarantee bounded transmission delays, but RTnet also includes a mechanism to tunnel non real-time traffic like TCP/IP over RTmac, thus allowing a "single-cable" solution for connecting control systems. Interestingly, this TDMA mechanism is optional, as you can deactivate it if you don't need it, perhaps because your network won't have collisions by design. Although this may sound strange, this is just the case if you are using your computer to communicate with some slaves using the EtherCAT standard.
RTnet is an Open Soure hard real-time network protocol stack for Xenomai and RTAI (real-time Linux extensions). It makes use of standard Ethernet hardware and supports several popular NIC chip sets, including Gigabit Ethernet. Moreover, Ethernet-over-1394 support is available based on the RT-FireWire protocol stack.
RTnet implements UDP/IP, TCP/IP (basic features), ICMP and ARP in a deterministic way. It provides a POSIX socket API to real-time user space processes and kernel modules.
  • Using RTnet in our EtherCAT master computer.



EtherCAT  常見問題問答
  
1. EtherCAT 技術

1.1 EtherCAT  比我的應用需求快，我為何還要使用它? 
A:卓越的現場匯流排性能絕對不會產生危害。即使是對慢速控制，它也可以提高反應時間和減少配置工作量，因為缺省設置將做這些事情。如果你對性能不是十分在意，也可以使用 EtherCAT 的其它優點：如低成本、靈活的網路拓撲結構或使用簡單。
  
1.2 EtherCAT 為什麼具有價格優勢? 
A: 有幾個方面的原因：
低廉的從站控制器使從站設備的價格也很低廉。無需專用的主站卡，主機板集成的乙太網控制器足已勝任。無需交換機或集線器，因此，降低了基礎結構的價格。使用標準電纜。實現簡單，因此，降低了施工費用。支援自動配置，無需手動設置位址，因此，降低了配置費用。
  
1.3 EtherCAT 僅限於主/從應用嗎? 
A:不是。和任何即時工業乙太網系統一樣，一個設備(主站)負責網路管理，並調度介質存取控
制。使用 EtherCAT，從站到從站的通訊有兩種方式：拓撲相關，並且在一個通訊週期時間內完成；以及拓撲無關，並且在兩個通訊週期時間內完成。由於 EtherCAT 比競爭對手的系統速度更快，使用兩個週期時間的從站到從站的通訊也更快。
  
1.4 EtherCAT 為什麼劃分為兩個不同的實體層? 
A:EtherCAT 在標準的 CAT5 電纜上使用標準的 100BASE-TX ("快速乙太網")。由於EtherCAT 也可以作為模組化設備的“底層匯流排”使用，一種價格更低的、使用 IEEE802.3ae 標準的實體層被添加到這樣的應用：
LVDS(也稱為：E-Bus)。在這些模組化設備之外，該實體層又被重新轉回到 100BASE–TX 方式。
  
2. EtherCAT 技術組

2.1 我需要成為 ETG 會員才能使用 EtherCAT 嗎? 
A:不需要。但是，你可以考慮加入 ETG 以表明你的興趣，並向你的供應商和客戶提供該技術的支援。作為
 ETG 會員，你將被邀請參加 ETG 會議，獲得技術資訊的許可權，起草規範，並且參與 EtherCAT 技術發展的方向。

 2.2 我需要成為 ETG 會員才能實施 EtherCAT 嗎? 
A:不需要。但推薦成為 ETG 會員的同時使用 EtherCAT，由於 ETG 會員可以享受更好的支援，獲得起草 EtherCAT 規範的許可權，樣本代碼，評估工具和其它支援的工具以及資訊(僅限於 ETG會員)。他們可以被邀請參加 ETG會議，回顧和討論規範。而且，ETG會員可以在EtherCAT網站上促銷他們的產品，並且可以在主要的展覽會上加入 ETG的聯合展臺。

2.3 ETG 會員為什麼是免費的? 
A :獲得開放技術的許可權不應因為會員年費或其他重要的費用而成為問題。不僅加入 ETG會員是免費的，
而且協定文檔、樣本代碼、評估工具、實現支援和其它服務甚至也是免費的或象徵性地收費。


2.4 ETG 的免費會員制將改變嗎? 
A:到目前為止，還沒有計劃更改 ETG會員制。如果將來需要會員費，(例如：由 ETG提供支援的其它服務
)，則會員管理委員會將採取這個決定。
  
2.5 ETG 會員如何進行技術“切磋”? 
A:在 ETG大會上詳細發表和討論 EtherCAT技術。鼓勵會員隨時提出評論、建議和修改方案。這些回饋和使用者、OEM、系統集成商以及設備製造商的需求都是很有價值的，也是很受歡迎的，並在具體實現時進行考慮。ETG 的發展歷史表明，這種運行機制非常有效。技術用戶與開發者的直接和面對面的接觸，可以進行技術訣竅和技術資訊的深入交流。
  
3. EtherCAT: 開放式技術

3.1 EtherCAT是開放的技術。其含義是什麼? 
A:它表明：任何人都可以使用、實現和受益于該項技術。同時也表明 EtherCAT 實現的相容性，任何人都不能改變這項技術，並阻止其他人使用。EtherCAT 已成為公共規範，並由 IEC (IEC/PAS 62407) 發佈，目前正在實施將其集成到現場匯流排國際標準 IEC 61508 之中。
  
3.2 EtherCAT 有專利嗎? 
A:是的。EtherCAT 技術有專利，就象其它的現場匯流排技術也存在專利技術一樣。EtherCAT 技術提供了唯一的專利特徵和授權，以保護它們不被複製或偽造。
  
3.3 EtherCAT 如何授權? 
A:實現 EtherCAT 主站可以免費。對於 EtherCAT 從站設備而言，已經採用了 CAN 的授權模式 (CAN 
是一個極好的保護標準開放式技術專利的例子)：小費用的授權被"嵌入" 到從站控制器晶片中，因此，設備製造商、最終使用者、系統集成商、工具製造商等不再需要支付授權費用。

3.4 EtherCAT 從站控制器有多種供貨管道嗎? 
A:是的。Altera (FPGA) 可以提供 EtherCAT 從站控制器，Hilscher (netX) 也可以提供 Beckhoff 的控制器。其它實現方式將隨後展開。

3.5 ASIC 將取代 FPGA 嗎? 
A:不會。FPGA 是多功能的、與設備製造商無關的和廉價的解決方案 – 而不是僅僅限於集成附加的設備功能。基於 EtherCAT 介面的 FPGA 價格已經低於市面上的現場匯流排界面價格 – 並且其價格還有可能進一步降低。因此，今後仍將實施 FPGA 的進一步開發。
  
4. 實施費用

4.1 FPGA 如何授權? 
A:當你從所希望的半導體分銷商處購買 FPGA 時，EtherCAT 代碼並沒有被裝入。因此，需要購買一次性的、公司性質的授權，價格：8000.00 歐元。該授權可以授予你大量製造 EtherCAT 的從站設備。今後，如果你決定從 FPGA 實施方式開始轉向 ASIC 實施方式，則不再需要該授權 – 你所需要的一切都包含在從站評估工具包中。


4.2 FPGA 的價格是多少? 
A:ETG 會員公司被授予了特殊價格用於購買 FPGA，即 EtherCAT 的價格低於市面上流行的現場匯流排界面價格。
  
4.3 我們需要什麼才能實施 EtherCAT 從站設備? 
A:EtherCAT 從站實施工具可以從幾個供應商處得到。例如，一個工具包包括一個帶 EtherCAT 從站控制器的從站設備評估板、從站協定原始程式碼(簡單設備選項)，硬體設計資訊參考手冊、EtherCAT 主站評估授權、手冊、電纜和 100 個從站設備授權。該套工具包價格為 430 歐元。
  
4.4 我們需要什麼才能實施 EtherCAT 主站設備? 
A: 對於主站設備，不需要專用硬體。任何乙太 MAC 都可以勝任。因為 EtherCAT 對資源的適應性很強，
無需專用的通訊處理器。主站代碼也可以從幾個供應商處得到，範圍包括免費的示例代碼、或包含
 RTOS 的 1000 個產品的樣本代碼包。實現服務也可以從幾個供應商處得到。


名詞解釋

現場總線 是許多工業用通訊協定的總稱，一般用在即時分散式控制系統，IEC 61158(現場總線規範) 是有關現場總線的標準，不過也有一些現場總線未列在 IEC 61158(現場總線規範) 中，如Modbus、LonWorks、
CANopen等。

現場匯流排是指以工廠內的測量和控制機器間的數位通訊為主的網路，也稱現場網路。也就是將感測器、各種操作終端和控制器間的通訊及控制器之間的通訊進行特化的網路。這些機器間的主體配線是ON/OFF、接點信號和類比信號，通過通訊的數位化，使時間分割、多重化、多點化成為可能，從而實現高性能化、高可靠化、保養簡便化、節省配線（配線的共用）。

    一個複雜的自動化系統（例如組裝生產線）會需要一個有組織的控制系統階層才能運作。在此階層的頂端一般是人機界面 (Human Machine Interface, HMI)，可以讓操作員監控及使用此系統。中間層則由許多可程式邏輯控制器（PLC）組成，PLC 之間藉由網路系統（如 Ethernet）傳遞資料。低層則是由現埸總線連接 PLC 及感測器、致動器、馬達、開關、閥門、接觸器等實際動作或偵測的元件。

現場總線科技在1988年就已產生，並且有相關的標準ISA S50.02，但國際標準的發展花了一段很長的時間。1999年時國際電工協會（IEC）的SC65C/WG6標準委員會開會，設法解決在IEC現場總線標準草案上的差異及歧見，會議的結果形成了第二版的IEC 61158標準，其中有八種（type）不同的通訊協定：

這種形式的「標準」一開始是為了歐洲共同市場所訂定，不著重其共通性，達成了消除各國家之間貿易限制的其主要目的。在第二版標準完成後，形成了一個的委員會SC65C/MT-9來修正IEC 61158標準中彼此不一致的格式及內容。上述標準的修正已進行的相關完善。

IEC 61158的現狀


在2008年國際電工委員會提出新的現場總線標準IEC 61158，將現場總線相關的標準分為15個通信行規族（Communication Profile Families, CPF）[1]：


參見[編輯]



外部連結[編輯]



參考資料[編輯]


  1. ^ Serving global industrial automation: IEC publishes new Fieldbus Standards. 國際電工委員會（IEC）. [2010-12-14].
  2. ^ WorldFip現場總線綜述. 自動化網論壇. [2010-12-14].
  3. ^ EPA簡介. 控制工程網. [2010-12-14].




IEC61158第四版國際標準的20種現場匯流排



1 、現場匯流排國際標準制定過程
     國際電子電機委員會極為重視現場匯流排標準的制定，早於1985年就籌備成立了IEC/TC65/SC65C/WG6工作組，開始起草現場匯流排標準。由於各國意見很不一致，工作進展十分緩慢。經過近十年的努力，IEC61158。2現場匯流排實體層規範於1993年正式成為國際標準；IEC61158。3和IEC61158。4鏈路服務定義和協定規範經過5輪投票於1998年2月成為FDIS標準；以及IEC61158。5和IEC61158。6應用層服務定義與協定規範於1997年10月成為FDIS標準。 1998年9月，IEC61158 FDIS草案進行最後一輪投票，決定是否成為國際標準，投票結果是支持率68%，反對率32%。由於反對票大於25%，現場匯流排標準未獲通過。隨後的10月，IEC/TC65在美國休士頓召開年會對投票結果進行了充分討論，經過充分協商，SC65C決定將FDIS於1999年一季度作為技術規範出版，於是產生了IEC61158第一版現場匯流排標準。 長期的爭論並未到此結束，各國代表為了各自的利益，隨後提出了各種修改IEC61158第一版技術規範的動議。為此，執委會做出CA105/19決議，要求SC65C修正目前的技術規範，使其包含至少另外一種行規。遵照CA決議和IEC主席的要求，SC65C/WG6工作組於1999年7月21日至23日在加拿大渥太華召開了工作會議，討論制定單一標準的，多功能的現場匯流排標準。本次會議共有8個匯流排組織的代表參加，會議討論了IEC TS61158的具體修改以及時間表。根據渥太華會議紀要IEC65C/218/INF，新的IEC61158將保留原來的IEC技術報告並作為Type1，其他匯流排將按照IEC原技術報告的格式作為Type2至Type8進入IEC61158。新版標準將採用的8種類型為:TS61158，ControlNet，Profibus，P-Net，FF HSE，SwiftNet，World FIP以及Interbus現場匯流排。2000年1月4日，經IEC各國家委員會投票表決，修改後的IEC61158第二版標準最終獲得通過。至此，IEC/SC65C/WG6現場匯流排工作組工作告一段落，IEC61158標準的修訂和維護由新成立的MT9維護工作組負責。為了反映現場匯流排與工業乙太網技術的最新發展，IEC/SC65C/MT9小組對IEC61158第二版標準進行了擴充和修訂，新版標準規定了10種類型現場匯流排，除原有的8種類型，還增加了Type9 FF H1現場匯流排和Type10 PROFINET現場匯流排。2003年4月，IEC61158 Ed.3現場匯流排第三版正式成為國際標準。
2、 IEC61158 Ed.4標準的構成
IEC61158第四版是由多部分組成的，長達8100頁的系列標準，它包括: 
IEC/TR61158-1 總論與導則； 
IEC 61158-2 實體層服務定義與協定規範； 
IEC 61158-300 資料連結層服務定義； 
IEC 61158-400 資料連結層協定規範； 
IEC 61158-500 應用層服務定義； 
IEC 61158-600 應用層協定規範。 
從整個標準的構成來看，該系列標準是經過長期技術爭論而逐步走向合作的產物，標準採納了經過市場考驗的20種主要類型的現場匯流排，工業乙太網和即時乙太網，具體類型詳
3、  進入IEC61158第四版國際標準的20種現場匯流排
進入 IEC61158 Ed.4 的20種現場匯流排類型如下表：
 類型
 技術名稱
 類型
 技術名稱
 Type1
TS61158 現場匯流排 
 Type11
TCnet 即時乙太網
 Type2
CIP 現場匯流排 
 Type12
EtherCAT 即時乙太網  
Type3
Profibus 現場匯流排 
 Type13
  Ethernet Powerlink 即時乙太網
 Type4
P-NET 現場匯流排 
 Type14
EPA即時乙太網  
 Type5
 FF HSE 高速乙太網
 Type15
 Modbus-RTPS 即時乙太網
 Type6
 SwiftNet 被撤銷
 Type16
 SERCOSⅠ，Ⅱ 現場匯流排
 Type7
 WorldFIP 現場匯流排
 Type17
 VNET/IP 即時乙太網  
 Type8
 INTERBUS現場匯流排
 Type18
  CC_Link 現場匯流排
 Type9
  FF H1 現場匯流排
 Type19
 SERCOS Ⅲ 即時乙太網
 Type10
PROFINET即時乙太網 
 Type20
 HART 現場匯流排
     表1中的Type1是原IEC61158第一版技術規範的內容，由於該匯流排主要依據FF現場匯流排和部分吸收WorldFIP現場匯流排技術制定的，所以經常被理解為FF現場匯流排。Type2 CIP(Common Industry Protocol)包括DeviceNet，ControlNet現場匯流排和Ethernet/IP即時乙太網。Type6 SwiftNet現場匯流排由於市場推廣應用很不理想，在第四版標準中被撤銷。Type13是預留給Ethernet Powerlink(EPL)即時乙太網的，提交的EPL規範不符合IEC61158標準格式要求，在此之前還沒有正式被接納。
詳細資訊可以點擊以下閱讀
 http://codms.cname03.com/files/pic/2011413184512.gifType3 PROFIBUS 現場匯流排簡介
http://codms.cname03.com/files/pic/2011413184512.gif Type10 PROFINET 即時乙太網
 http://codms.cname03.com/files/pic/2011413184512.gifType4 P-NET現場匯流排技術
http://codms.cname03.com/files/pic/2011413184512.gif Type11-TCnet即時乙太網
 http://codms.cname03.com/files/pic/2011413184512.gifTType14-EPA即時乙太網
http://codms.cname03.com/files/pic/2011413184512.gif Type12-EtherCAT 即時乙太網簡介
 http://codms.cname03.com/files/pic/2011413184512.gifType18 CC_Link 現場匯流排
http://codms.cname03.com/files/pic/2011413184512.gif Type13-Ethernet Powerlink 即時乙太網


参考文献]：
    [1]冯冬芹,金建祥,诸健.“工业以太网及其应用技术”讲座[J].自动化仪表,2003, (4)
    [2]楼敏.基于现场总线技术的大电流整流控制系统[J].化工生产与技术,2009,(1)
    [3]张其林.车间数字设备集成控制系统结构与嵌入式接口的设计[D].武汉理工大学,2006
    [4]张军.基于EPA工业以太网的智能变送器研究 [D].重庆大学,2006
    [5]缪学勤.现场总线技术的最新进展[J].自动化仪表,2000(6)
    [6]郇极,刘艳强.工业以太网现场总线EtherCAT驱动程序设计及应用[M].北京航空航天大学出版社,2012
    [7]姜晓林,韩江,夏链,成勇.现场总线与工业以太网的应用分析[J]现代制造工程:2006（3）
    [8] 刘载文,方平,张晓力.控制网络技术及其实时性分析[J]北京工商大学学报(自然版) :2005（1）
    [9]孔丽丽.基于EtherCAT波高数据采集系统的研究 [D].大连理工大学,2009
    [10]庄晓燕,周森鑫.工业控制以太网协议实现研究 [J].计算机技术与发展,2009(12)
    [11]梁瑾.基于以太网的网络控制系统的研究 [D].天津大学 ,2004
    [12]朱政红,王月娥 .工业以太网在控制领域中的实时性技术 [D].低压电器 ,2010（7）
    [13]缪学勤.论六种实时以太网的通信协议[J].自动化仪表,2005（4）
    [14]曹晶.EtherCAT从站设备的开发[D].武汉科技大学:2010
    [15]孔庆荣 .嵌入式以太网技术的研究 [D].哈尔滨工程大学,2008
    [16]邓荡荡.基于嵌入式系统的网络音频播放终端 [D].电子科技大学,2009
    [17]EtherCAT 技术协会中国代表处.EtherCAT——以太网现场总线——关于“为何选择EtherCAT”问题的技术解答[J].工业以太网专栏:2007(7)
    [18]EtherCAT Technology Group (ETG) . EtherCAT Slave Implementation Guide [EB/OL] . http://www.ethercat.org/,2012
    [19]林志磊. 基于netX芯片实现实时以太网通讯的研究与开发[D]. 北京工业大学,2010
    [20]李玉杰. 基于EtherCAT的从站微处理器的设计与实现[D]. 武汉理工大学,2012
    [21]Beckhoff Automation GmbH．EtherCAT_ET1100_Datasheet[EB/OL]．http://www.docin.com/p-322485754.html
    [22]刘新波. 基于实时以太网EtherCAT的卷烟机控制[D]. 华南理工大学,2011
    [23]ETG．EtheCAT Specification-Part 4 Data Link Layer protocols specification[EB/OL]．
    http://www.ethercat.org/,2010
    [24]Beckhoff Automation GmbH．EtherCAT_ET1100_Datasheet[EB/OL]．
    http://www.docin.com/p-322485754.html
    [25]Texas Instruments Incorporated . AM335x ARM® Cortex™-A8 微处理器(MPUs) [EB/OL] . http://www.ti.com.cn/cn/lit/ds/symlink/am3359.pdf
    [26]Texas Instruments Incorporated . 工业用温度10/100Mbs以太网物理层收发器 [EB/OL] . http://www.ti.com.cn/cn/lit/ds/symlink/tlk110.pdf
    [27]river_huang.网络变压器的作用[EB/OL].
    http://bbs.21ic.com/icview-232156-1-1.html:2011-4-25
    [28]车远强.基于物联网的中央空调节能控制[D].山东大学:2011
    [29]康存锋,林志磊,马春敏,黄旭东,费仁元 . 基于 TwinCAT 主站的 EtherCAT实时以太网分析与研究[J].现代制造工程:2010(11)
    [30]陈璋.基于PC-Based的液位监控系统的研究[D].大连交通大学:2008
    [31]修建竹.基于EtherCAT网络的实时控制技术研究[D].大连理工大学:2010
    [32]罗雨.海底管道铺设焊接机器人系统研究[D].北京化工大学:2012
    [33]韩东,郑玉忠,段冉 .EtherCAT实时以太网在卷接机组电控系统中的应用[J].工业控制计算机：2010（7）
    [34]单春荣,刘艳强,郇极 .工业以太网现场总线EtherCAT及驱动程序设计[J].制造业自动化：2007（11）
    [35]黄城.基于J2EE的远程教育考试系统分析与设计[D].电子科技大学：2012
    [36]EtherCAT Technology Group (ETG) . EtherCAT Slave Implementation Guide [EB/OL] . http://www.ethercat.org/,2012
    [37]修建竹.基于EtherCAT网络的实时控制技术研究[D].大连理工大学:2010
    

ETG.1000 EtherCAT Specification

張貼者： 於
標籤： ,

沒有留言:

張貼留言

注意：只有此網誌的成員可以留言。

訂閱： 張貼留言 (Atom)