[solved] Rehoming Lathespidle / Rotary-Axis from inside GCode

Note that this seems to be for spindle mode using the stepgen and not by switching the servo controller between postion and speed mode. Not sure of the implications of that.

Was wondering about that too.  My drive is capable of switching between the two modes using an input, and I presume NoJo's could too.

So why do the switch in LCNC?

First thought is that a drive usually (at least the ones I've come across) wants to see step/dir or pwm input for position, but isn't normally controlled in velocity mode using step/dir.  And I don't think you can switch between a stepgen and pwmgen on a Mesa card on the fly.

Wonder if tuning would be easier if the drive were controlled using both -10/+10v (spindle) and step/dir (position).  Trigger the drive's 'input source & mode' pins, and now you've got a velocity-mode drive.  Maybe the drive would behave better in each mode as your two LCNC PID's could be tuned for the correct mode rather than 'tricking' the drive when it's in position mode.  I'm probably overthinking this.

I also wonder if putting the drive in follower mode - as if it were slaved/geared to some other motor/drive - would be beneficial.  Using count up-down signals rather than step/dir.  Might make it easier to synchronize to a subspindle (or vise-versa).

switching between Mesa stepgen and the electronic spindle pot works fine. I can jog as rotary and as soon as I issue a spindle enable I can control the servomotor in speed mode using the analog input as soon a spindle is disabled I'm back to the stepgen and position control in the servo controller.
The problem is the encoder position changes when using the servo in speed mode which gets it out of sync to the joint motor position-fb. Hence the idea to orient the spindle to match the motor position-fb value before switching back to position mode.

I see, thanks.

I guess there's a subtlety in the sequencing variations, and I don't know which is 'better' or if it makes any difference:

• Scheme #1
  • C-axis homes to encoder index on enable/home
    • run some positioning moves
  • Switch to velocity mode
    • control method doesn't matter (analog or step/dir or pwm)
    • run spindle in velocity mode
  • Encoder is now out of sync with last axis position command
  • Switch to axis mode
    • reset encoder index
    • home C-axis
• Scheme #2
  • Same as above but instead of resetting the encoder index
  • Orient spindle before switching to axis mode (using orient.comp)
  • Switch to C-axis mode
    • no need to home axis?

I'm sure I'm missing something, but I wonder if orient will work well enough as the hand-off between a velocity mode and positioning mode?  I'd be concerned that the orient tolerance wouldn't match the axis following error tolerance, and you'd have to set the joint ferror tolerance high enough that subsequence axis-spindle-axis mode changes would result in misalignment between the two axis mode changes.

There (probably) wouldn't be an error accumulation over multiple axis-spindle-axis mode changes, but I fear using orient wouldn't nail the position each time the axis mode is enabled.

I would think that the encoder reset plus a forced C-axis homing to index at each positioning-mode enable would be the most accurate method?  That seems to be the scheme used in caxis.comp, and is also the method used on my Fanuc thing.

 

I agree that homing the rotary at each switch to positioning mode seems the most sensible approach. I'll need to have a closer look at the caxis.comp.

The caxis.com looking always with lathe eyes. What happens if you have a milling machine with toolspindle and A or C axis and want turning? Then we have two spindles and the story begins new. I think first step should be teaching lincnc that round axis only count max. 360° and second step supported rehoming. But i take a look in the homing.c and closed it. Behind my mind...
What do think about this idea? And is there someone who can do it?