HAL CiA402 Drive Interface for Can Bus,Ethercat etc...

After reading many questions and topics here in the last weeks, I determined that many users found the same stumbling blocks
in setting up an CiA402 standard servo Drive. Even if the Bus communication (EtherCAT) is working with the "generic" Driver, the handling of the Drives control or find the right scaling is not clear to everyone.

So I have splitted one type specific hardware driver, and created an standalone component.

github.com/dbraun1981/hal-cia402

Hal-CiA402 acts as an interface layer between the hardware communication(Can Bus, Ethercat, Profibus etc.) and provide the common linuxcnc hal pins for using the servo drive.

For installation clone or copy the comp file and install it with "halcompile --install cia402.comp" to your environment. Documentation/Examples can be found on github or in the comp manual.

My future plan is, to make an "generic_coe" native driver for linuxcnc-ethercat, so full configuration can be simple done from the ethercat_conf.xml an this component is not needed anymore. but time is ........

Hello,

i have overlooked one point, caused of my test setup.

For using the drives internal home procedure, please set your linuxcncs ini
home_latch_velocity to the same speed value as in the servo drive. If the speeds differ, you will got an f-error.

I will fix this on github, in the next few days.

thanks to JimPanski.

For using the drives internal home procedure, please set your linuxcncs ini
home_latch_velocity to the same speed value as in the servo drive.

Doesn't this require switching modes of the amplifierfrom CSP 0x08 to Homing 0x06 (Delta Amps)?
As well as modifying the homing.c and homing.h since in homing mode the amplifiers are in control not linuxnc during homing?

Dan

Also way back at the start of the ethercat hal driver thread Roschi discusses how he handled homing but he used absolute encoders which is much simpler than incremental.

The Drives mode are switched by the hal component,
We are using the drives internal homing at linuxcncs "wait for index" state, so at the moment the drives clears the index-enable bit, motion sets his counter to the drives value.

Hi Dominik,

now after a while setting up different other things I can finally use my drives with your component. Do you see chances to make the component intercept the demanded position while homing. I am getting a lot of following errors when the homing is ongoing although I am using the same homing speeds (in the drives and my ini file)

Hi Jim

I have been working on this same issue and have brought it up before in the ethercat hal driver thread but to no avail. IMHO I believe that the issue lies in homing.c file specifically where the homing routine does moving checks (this is only an issue with incremental encoders).

After several attempts at homing I ended up settling on the following
-use Roschi's method of setting the search velocity = 0 latch velocity = 9.9 in the .ini file
-modify the homing.c file (and the header file) to shortcut through the homing sequence so that it is perpetually waiting. The servo amps are in control, all you can do is e-stop during homing.
- mode switch via a custom homing button that calls a couple of custom m-codes to switch modes in conjunction with some ladder logic, then initiate the homing routine, then switches back to CSP mode via m-codes and ladder logic. The caveat to this method is that you cannot connect the position feedback to linuxcnc without getting a following error at some point in the routine. Usually when it  switches from search to latch velocity. Instead I use the amplifiers following error output to indicate when you are outside of the following window. Technically this is open loop and may seem counter intuitive but think about it, Delta has spent a lot of time money and time to develop the motion profiles and the encoder has over 1 million PPR. Why not rely on the amplifiers 1 ms cycle time and not be limited by the computers latency to calculate the following error. Note: if you run in velocity mode you need to reduce the encoder resolution down to 2500 PPR from 1 million.

That all being said in my mind, a better solution would be to have a variable in the .ini file that can be found by homing.c  Then homing.c has a routine that sets the commanded position = feedback position and loops until the servo is done it's internal homing routine. Similar to Dominik's HAL component.   Only by setting the search velocity equal to latch velocity in was I able to get this approach to work without a spitting out a following error. On a big machine like mine this is not practical.  For whatever reason though, I could never fully get this to work with two different speeds. Hence, my comprised solution...

Disclaimer:  Modifying the homing.c file may ruin your crops, spoil your milk and seriously wreck your machine...seriously.

Not sure if any of this helps but I think both solutions are trying to solve the same problem.  

Kind regards,
Dan

   




 

Hi Dan,
thanks for your detailed message. 
The thing is: I already messed with homing.c and got no luck doing this "homing shortcut". Even Roschi couldn´t help, maybe cause of many differences since 2.5 (or 2.6) he was using at the time he invented this changes. 
So as Dominik brought up his component I was really lucky to have that. With it I was finally in the situation to change my drives op mode and do the homing! (and also without needing extra cl - so only few lines in my hal file -VERY NICE!)
Now I think (have to check that) my drives put out the following error maybe during switching back to opmode 8 and lcnc having a different position at that time.

Cheers
Conny

Hi,

sorry but unfortunaly i have no hardware at the moment for testing.

but maybe you can test by your own.

insert this at line 238 in the component:

and do an reinstall.

This ignores the pos feedback from the drive while homing, but be aware there is no following error monitoring from linuxcnc during homing anymore.

Hi Dominik,

What happens if you have to hit an E-Stop during the homing routine? If the servo's actual position and LinuxCNC's position are not the same you can expect a very rapid move to the commanded position when the servo restarts after the estop. This happened to me during my experiments. Luckily no damage but it is mildly terrifying. 

@ Conney

I wouldn't write off classic ladder just yet, if your servo's have brakes like mine you need at least a 200 ms delay between switching modes for the brake to either engage or disengage. This is much harder to code than to insert a few lines of classic ladder. Also, presuming that you already have some sort of estop logic which IMHO must be tied to the amplifiers enable pin all you need is a second enable pin that you can toggle if you want to switch modes. I do this through a few custom m-codes. My two cents.

Kind regards,
Dan