Ethercat HAL driver

To Andy: LinuxCNC, I shall remember. There are also plenty of other web pages still using EMC2, but if you wish I will forget it.

To Andreas:

Thanks for tutorial, I see it is even more easy than I thought. I still don't understand what all drivers are used for and why lcec_conf is refering to them. I have to admit that c++ is hokus-pokus (kind of magic) for me. But at this point it would be helpful to get instructions from Sascha.
What I understood from your tutorial is that lcec_conf works also like a XML parser and original XML files have only to be rearanged a little, the rest is done automaticly.

The next thing I learned from mail archive of etherlab is, citation (Andreas Stewering-Bone ):

"Please also note, Beckhoff will switch to sdo and DS402 in future
products, SOE seems to be dead in the future products!!!!"

I thought Sercos is more general and non-product specific, so implementing one Sercos drive solves all of them in the future. Apparently I am wrong, no big problem if we can make our own driver for each device that runs with TwinCat.

Finnaly, I still don't have hardware to make a CNC, but I was awaiting this moment of decision to seek digital servo drives. It seems Ethercat (CoE) and Beckhoff coupler with IOs make perfect machine. ( I don't like soldering and buying PCI , Parallel port cards).

Regards Marko Bursic

Hi,

some thoughts to the last posts from you all:

I like the idea of a scaling/shifting parameter for the "generic" driver hal pin mapping. I will implement such a feature in the next version of the driver.

If you like to do some SDO initialization it is already possible with the generic driver. Please see this example:

currently only sdoDataRaw is supported but you can gather the hex data from TwinCAT (I wish I would find the time to complete the doc in not-so-far future). The Idea is to support other datatypes (Primitive types like int/float/bool, enums, complex device dependent types) in the future.

Please don't confuse about the device description xml's (the ones you can download from Beckhoff for example) and the hal driver config file. They follow a completely different syntax since they have have different functions. But it should be possible to create a tool like the TC device manager to create the hal driver config xml automatically (based on the device description xml's).

I am still searching for a better concept to do the PDO level to HAL pin level mapping. One idea is do implement an additional abstraction layer. One of the advantage of such a concept could be the transport independent implementation of the domain data processing. That way we could implement several transport layers (EtherCAT, CanOpen, HOSTMOT PCI, HOSTMOT Ethernet, Modbus and so on) that operate on some kind of "raw" data level and an adapter layer to "high level" hal pins. For example all the different flavors of encoder inputs share nearly the same logic. But currently I'm not sure if that would be a practical option.

Hi,

my philosophy for using EtherCAT devices such as servo drives is to do as much as possible with the software deliverd with the drives. So all settings,parameters, etc. that should and could be done only once are outside of HAL or LinuxCNC.
That means for my case (use of IndraDrive) that also the PDO assignment is only done once via Beckhoff-Software. The HAL-Driver therfore only needs to know about the addresses of the syncmanager registers and the assigned PDOs and didnot need to assign them again (CoE isn't supported by IndraDrives so the assignment won't work with the EtherCAT HAL driver).

Therefore the 'generic' EtherCAT HAL driver works best and should do for all EtherCAT devices.

To get a little more generic I have added an additional hal-type in the XML file which configures the EtherCAT HAL-Driver.

So as an example a part of the file can look likeTherein you can see the halType="special32" and a scale="10000". This leads to a hal-pin with data type float and calculate scaling.
So the interface in the *.hal files to the EtherCAT are simple and straight forward because the values are deliverd e.g. in mm or mm/min.

@sascha:
I've put the modified code to a github repos which is forked from yours. Perhaps this is the same idea that you have and you can check the functionality with some other devices.
And yes alittle tool to rearrange 'original' XML files to the one needed for EtherCAT HAL driver would be nice. I think this could be directly implemented in the lcec_conf.c

Regards Andreas

Hi,

on the topic of licenses
see the opinion of the developer of the IgH EtherCAT Master Mr. Pose
lists.etherlab.org/pipermail/etherlab-users/2008/000249.html
It is from 2008 and I'm sure looking at their website this still holds


According to this Document
ethercatmaster.berlios.de/files/EtherCAT...icense_Agreement.pdf

In my opinion there is no conflict with laws/patents there is 'only' a conflict in philosophy and minds.

Regards Andreas

Hi sascha,
According to EtherCAT? realtime HAL driver , there should have a ethercat driver in <source-path-of-LinuxCNC>/src/hal/drivers/ethercat/master/debian. However, the directory was removed on Aug-25-2013 from git log. Can I know how do I patch the driver into IgH Ethercat master? Or does that mean your code not need to patch IgH ethercat master now?


Thanks you in advance,
Wen

[Update] The package seems moved to here . I will study them and the tutorial in previous post. Thanks again.

From my point of view, the real-time communication is better to be consistent. I wouldn't mix on the same network ethercat, modbus, ethernet... I would use a second NIC instead. There are few real time protocols that use ethernet as physical layer: Ethercat, Profinet, Sercos iii,..., others are non-real time and I don't see the need of implementing them in RT part.

Next, with use of Ethercat drive, you will always have to use an engineering tool provided by servo manufacturer. Each servo drive is one autonomous device, with its paramaters, you may also want to tune, adjust servo loops, etc...the connection to external world is communication (Ethercat). The PDO is choosen to suit the application needs, can be pre-prepared standard telegram or user made PDO list. Once the PDO list is choosen we need to link PC and drvie together, Bekhofff uses its own configurator while we want to have our own HAL configurator.
Now, if we stop and look arround we will notice that all Ethercat drives shall support Beckhoff TwinCAT (same is with Profinet, all drives shall support Siemens software).
Currently the proposed way is to use TwinCAT configurator to configure PDO list, so that it matches one configured in the drive and then export it in XML file and rearange it to match linuxcnc ethercat generic HAL driver, however if you use terminal blocks of Beckhoff there are already made HAL device drivers.

The only license problem as I see is that you need to reverse-engineer XML output file from TwinCAT configurator, and of course you need a licensed TwinCAT software. As I don't have the knowledge in laws, I don't understand all paragraphs in licenses declarations. With my logical thinking my modest conclusion is that we are not allowed to make a slave EtherCAT device, master use is possible as IgH sells its own kits for professionals and there is no mention about some fee to 3rd party.

As I work with Lenze servos, I tried to configure one drive with Lenze L-Force Engineer software. A nice feature is pre-prepared configuration with CIA402 drive profile telegram, I did further research over internet and have found that also Omron, Moog, Mitsubishi, Stoeber and many others support the configuration of standarized telegram named CiA402 drive profile. May this be a good start point to embed in linuxcnc, a device driver compatible for many servo drives.

Regards, Marko.

From: www.ethercat.org/en/faq.html#3370

3.3 How about licenses?
The license for implementing an EtherCAT master is free of charge. For slave devices EtherCAT has adopted the CAN license model (CAN is an excellent example for a standardized open technology that is protected by patents): The small license fee is "embedded" in the EtherCAT Slave Controller (ESC) chip, so that device manufacturers, end users, system integrators, tool manufacturers etc. do not have to pay a license.

3.4 How about Open Source?
EtherCAT technology itself is not Open Source. Backed by the standardization of EtherCAT by IEC, ISO and SEMI, access to EtherCAT technology is available to everyone to non-discriminatory terms. Additionally, Master Licenses are free of royalties. Maintenance and all further development of the technology is available to all users by membership within the ETG, the user group for EtherCAT technology. If you have questions regarding implementing or using EtherCAT in conjunction with shared source or open source systems please contact ETG headquarters or Beckhoff, the EtherCAT technology licensor.