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

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

 

Hallo Dominik,

für Profibus wird das so nicht funktionieren.
Hier muss in den Telegrammen das Low-Byte mit dem High-Byte getauscht werden.
Ich hatte mir hierfür eine Comp geschrieben, ist zwar mit Sicherheit nicht sauber abter tat was es soll.

Gruß

Andre

Hi,

@sqmathlete
E-stop should not be a problem. If nobody changes motion source in the last months,
linuxcnc resets its position to the feedback position in the case you switch power on again. otherwise every following error would not be resetable... Have your experiments been with my component?

Brake
normaly brake handling is done in the drive, also the neccesary delays that needed for power on/off. If you set/reset enable, the drive returns his powered on signal after external brake is ready and the control loop is running.