Implementing Spindle Homing for DELTA C2000 Plus (In)correctly?

Sorry for the double post, messed up the formatting of the original one with an edit.

Hello everyone,

I've been trying to set up a DELTA C2000 Plus control drive with LinuxCNC over EtherCAT for a spindle motor and I am having difficulties with the homing (what seems to be the bane of many LinuxCNC users)...

The hal-cia402 driver does not seem to work properly, as the controlword is not being passed correctly and the model does not support CSV mode, which seems to be something the cia402 driver relies on. There is a ready driver for a different, but very similar model, the DELTA MS300. The PDOs are the same, so getting it to run was as easy as changing the pid in the source and recompiling. However, this driver only supports Velocity Mode, even if it works well. Homing Mode is something I am trying to figure out how to implement myself, but sadly I am not well-versed enough to manage on my own.

Would it be a good idea to try to put the following section from the cia402 source into my driver, changing the variable names where appropriate and changing CSV Mode to Velocity Mode:
Do you think this approach is correct? Another thing I've tried is to set it to home over PLC, as the model supports that. But it does not look like it will suit our purposes, as the drive interrupts the EtherCAT connection when switching to PLC mode, which causes unexpected behavior.

I am using the CMC-EC01 extension card for the drive and the homing is intended to be handled by an Origin Switch as the encoder is incremental. I will attach the linuxcnc-ethercat driver for the MS300 for the sake convenience.

Using the EMC-PG01H card for the encoder too, but the encoder is not relevant for the homing. I think. I will tackle that once I get to the spindle orientation...

I appreciate any help and suggestions!

on the surface this appears like it should be correct , but I am not expert with ethercat, far far from it. it appears your checking for the home comparison and setting 0 or 1 based on that result, then issuing a home command if not homed. The next issue obviously will be having linuxcnc call the homing in the driver. Is this to be used as a C axis, if not just have it call the homing function in your postprocessor iirc

forum.linuxcnc.org/10-advanced-configura...7-homing-the-spindle

Thanks for the response, Collins.

That thread is more concerned with the spindle orientation with M19, is it not? Or do you mean to imply I can implement both M6 homing + tool changing and M19 orientation with this? Would this work with an incremental sin/cos encoder with an origin switch instead of an absolute encoder?

One of the responses in that thread was a link to a more recent solution to the spindle homing:
forum.linuxcnc.org/10-advanced-configura...nt-component-revised

I suppose it would be best for me to look into that, as it seems people are pleased with it.

I was under the impression the homing should be handled internally by the drive upon being sent the appropriate command by LinuxCNC over EtherCAT. After all, it does have a "Homing Mode." But it seems that is not necessary and I can handle it all through the orient component (or the more recent solution) which calculates the homing through the encoder feedback? Am I understanding this correctly?

Also, what is the index-enable these components refer to? Is that the origin switch of the motor?

Thanks again for the help.

index enable usually refers to the Index output of the encoder, basically it's a single pules indicating the encoder has reached the reset point of it's wheel. IE every 2048 pules in a 2048 encoder you get a index pulse. if so equipped, often referred to as the Z pulse in many encoders.

Thanks for the overview.

I don't think that will work for me, as my encoder doesn't have a Z pulse. Just an A, B and R one. The motor itself has an origin switch that gives a digital output. The idea is to have that serve as the homing point, probably by using Homing Method 4 for Homing Mode (an operation mode in EtherCAT). I'm going to look into whether or not something like this has been discussed here, but for now it seems I'm the only one with this sort of setup, I think.

the origin switch is probably what your after, but you might want to make sure it consistently repeats to within a few encoder counts every time or it's useless for things like threading etc.