Open Discussion In Regard To Motion Control Only Drivers For ECAT/LCNC

All,

As with many things in the LCNC world there are hundreds of variations of setups for various machines. Mills, Lathes, Plasma, Laser, Warerjet, etc. The list goes on and on. There are several methods and hardware devices that connect with LCNC to drive motion control ECAT being one of them. While it is ignored by most due to the price overhead, there are many who seek to use this technology for the benefits it brings forth. The main one being a deterministic model that just works. Nearly plug and play. Very precise motion control. etc...

As most know who are familiar with ECAT each OEM of a hardware device must supply an ESI/XML file to describe their hardware to the CANopen bus. The schema is a hard model created by the EtherCat Foundation. Ever OEM must use specific data types, and specific registers in accordance with a standard. PDO 6040 for example. You get a total of 8(4 Rx and 4 Tx) as well as a slow bus set on the SDO channel which are updated at the 100ms tick on the DC(Distributed Clock). These standards are setup to ensure that all the data looks exactly the same. Say I have an Omron drive and a Delta servo on the same system. No worries. They use the same ECAT pipe and you can basically just use the same xml description for both nearly interchangeably. Now, there are abilities to use the SDO channels to send parameters, messages, etc. but those are not required. Each drive has their own set of those although most simply mimic each other overall. 

I will never pretend to be an expert, but I think that much of the discussion on this channel has to do with a misunderstanding of the problems ECAT tries to solve. ECAT is a simplification model. That means, that if ever device connected speaks the same language the actual system becomes nearly plug and play. ECAT is not designed for a system that fits the needs of the individual but the collective of users so that user A can get the same performance as user B. In order for that to happen ECAT made the OEM's who are registered ECAT hardware providers conform to a specific standard. The 5000+ members(OEM's) all agreed. So for the past 20 years, that standard has stood as the pedestal that makes ECAT such a popular approach to motion control. Speed and standards. 

All that said, LinuxCNC is an Open Source software. So is EtherCat. Simply because Open Source is open does not mean that some level of standards should not be employed to ensure each person who chooses the LinuxCNC or EtherCat system will have a solid and successful result. If the user wants a specific duty system, then they should be solely responsible for the development and maintenance of their custom system. That system may end up being the best practice, but most times it is not the case. If EtherCat is going to ever be a solid method to integrate servos with LCNC, then a standard driver must created that all registered servos can use to connect with LCNC. Currently, the Generic Driver works. But, that driver merely handles the PDO side leaving the SDO side alone as far as I can tell. 

So here are the pain points of EtherCat with LinuxCNC as I see them:

1. The Generic Driver works with most drives but is very simplified. Currently if your drive is not listed, there is no .h/.c driver specific to your hardware so you must use the generic version and good luck with the .h/.c drivers if you want to extend your usage of the drive.
2. If you use the OEM ESI, you must have a .h and .c file to accompany it or else it fails to compile. (NOTE: In most Masters the parse file merely uses the <Vendor> section to record it in the dictionary. The only thing the driver needs is the device info to build the OD(Object Dictionary. LCNC uses the drivers to create the required Hal pins for the device. As far as I can tell from the schema standards all registered devices use the same registers that are exposed to the bus.).
3. Homing is a drag. Even though the drives(Registered) have their own internal homing and merely need the master to say hey you, go home and let me know when you're done, many are trying to use the LCNC homing model. Using the LCNC homing method has to be modified to allow the drive to do that work. LCNC just needs to butt out for a bit. This has many trying to make a "custom homing method". Which I think has to be done, but as I see the code behind it LCNC is involved in the process at the micro or weeds level. LCNC should be at the macro level. Set OP6 mode and wait. Drive done, LCNC updates ABS machine position, and records the axis as homed. The method of how the drive did that "homing" is none of LCNC's business. Just that LCNC said, go home and the drive said, yeah like I did it bro. This is known as a separation of concerns. With EtherCat involved, LCNC no longer controls motion nor needs a closed loop feedback or even semi-closed. It is just passing messages it parses from your GCODE. Period. 
4. Drive Error Channels are not piped. These come form the SDO side on the slow bus.
5. there are way more so please add to the list...

All in all, LinuxCNC is already complex to set up. EtherCat was designed to not add additional complexity. Let's start discussing what is involved in creating a standard working driver that will parse properly any imported esi/xml file from the OEM's. There are thousands of them. It seems illogical at best to have this massive code base for each and everyone of them. And to expect for those files to be maintained. 

If the Generic file works, let's update the driver so that more than just simple PDO's can be parsed. Let's decide which SDO's to include or make optional that can be parsed as well. This way, we can write specific parameters like EG values, max velo, and read the error stream on failure. A truly generic but robust driver that works with 90% of all drives regardless of OEM. If the VendorName is set to Generic so be it. The dictionary saves it as that. But is it says, "Joey Bag Of Donuts", the driver should be able to stored that in LCNC as well as the productType in an accessible format from LCNC. Maybe a .var file? Then if in QtPyVCP, you can access the file and display the list of connected devices on the machine screen in a table. 

I sincerely hope this discussion brings real change that helps everyone now and going forward. LinuxCNC is not just free, but after 30 years of CNC control engineering the motion control output parallels Siemens, Fanuc, and Heidenhain. So much so that a lot of the code base for these high end controls comes from LCNC. Heidenhain especially. It would be awesome to have a system that any common man can build without having to sell his entire family to pay for it. 

Sincerely, 

Don

First lets get a clear understanding of what the landscape is before launching any proposed enhancements.

1. Linuxcnc does not include any Ethercat code becasue we can never be members of the Ethercat Technology group becasue we are not a company.
2 Linuxcnc's implemenation of ethercat depends on the igh ethercat master etherlab.org/en_GB/ethercat
3.The generic driver is part of the igh master not linuxcnc
4. igh now host their ethercat master on a repository
5. The linuxcnc hal driver now lives in a repo managed by Scott Laird github.com/linuxcnc-ethercat
6. Scotts repo links to a buildbot that then publishes our hal driver debs on the igh repository that hosts their ethercat master
7. The Linuxcnc 2.9.2 installer on the Linuxcnc downloads page sets up  apt so it can install the packages hosted by igh
8. Dewey Garrett modified linuxcnc's homing model so it spports a custom homing module but few people have used it.
9. I have a CIA402 custom homing module which once fully tested should become part of Scott's driver. github.com/rodw-au/cia402_homecomp
10. Scott's hal driver also includes modules for generic cia402 devices (and some specific cia402 devices)
11. Scott's cia402 drivers and a custom homing module is dependent on Dominic Braun's CIA402.comp github.com/dbraun1981/hal-cia402
12. Dominic's component also attempts to do homing stuff but only for a drive with absolute encoders.

So with all of that in mind these are the first steps to move forward:

1. the cia402 custom homing component needs to be tested and merge into Scott's hal driver
2. Dominic's component needs cleaning up to suit the new landscape and preferably merged into the cia402 custom homing component or Scott's cia402 driver

I am waiting on some hardware that will allow me to build a cia402 homing test bed.