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 like Therein 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

I asked if it would be possible to include this in the next release of LinuxCNC. Unfortunately it appears that the terms of the Beckhoff license are incompatible with the GPL, so this will never be possible. This seems like a real pity.

thread.gmane.org/gmane.linux.distributions.emc.devel/11297

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

roschi wrote: 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.

Indeed, I don't think that there is any legal problem. The problem is that LinuxCNC is distributed under the terms of the GPL, and the GPL prohibits distributing software linked to packages that are not themselves GPL.

I don't think that there is any problem with the EtherCAT HAL driver existing, nor with any user installing and using it on their own system, but I don't think it is possible to distribute it as part of the LinuxCNC package whilst still stating that LinuxCNC is "Free" software in the GPL sense. (Because anyone further distributing LinuxCNC would also have to sign that additional license).

I would be extremely happy to be proven wrong in this.