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

excellent thread guys, I'll look at caxis.comp and see if i can figure it out

Aciera wrote:

@spumco
Thanks, actually that is probably what made me think that there was a component to switch between rotary and spindle. Seems it's not really as simple as recycling a component though.
I think NoJo ended up doing a fair bit of customizing in the source code that was not shared at the time.
 

Nothing is ever simple with LCNC, is it?

From what I gathered, I think the backstage fiddling he had to do was because he wanted switchable kinematics (Polarkins) available via m-codes.

Plowing back through some of the comments I made to him when he was starting out I was reminded of something I wrote earlier... I don't think we need polar interpolation.

When I look at the code Fusion 360 outputs for my commercial C-axis live-tool lathe, there's no polar interpolation.  It's all done in the post processor.  My control has polar interpolation internally, but my post processor doesn't use it - it just outputs X/Z/C moves, having done the Y->C  gymnastics inside the post.

I've no intention of hand-coding a radial cam groove on a shaft - the sort of thing you really want polar interp for in a control.  F360 can handle that one as far as I'm concerned.

If NoJo's implementation was that fussy, I don't think it's necessary, at least for my use-case.  What I'm interested in is C-axis indexing (at the moment) as well as a dual-purpose velocity/positioning spindle.  And his caxis.comp plus HAL config appears to accomplish that without anything seiously 'advanced'.

-R

smc.collins wrote:

excellent thread guys, I'll look at caxis.comp and see if i can figure it out
 

NoJo's responded in his original thread I drug up... I suspect he will be able to shed some light on the whole shebang.  Might want to pay attention to that one, too.

Your insights are also, as usual, most welcome.  I tend to grab my popcorn and thinkin' cap when I see you post something.

I am thinking about handling the c axis and spindle by controlling the encoder signal by using the enable for each, and then using macro's to force the rehoming of the axis or spindle orient on each enable. IE if spindle is enabled, call orient from a macro and  then have the output sent to the spindle encoder , when in c axis, the encoder output is sent out to C axis then macro calls home and resets encoder. at least, that what I have worked out in theory. This functionality really needs to be integrated into linuxcnc at it's core.

smc.collins wrote:

 IE if spindle is enabled, call orient from a macro and  then have the output sent to the spindle encoder , when in c axis, the encoder output is sent out to C axis then macro calls home and resets encoder.
 

Do you think you need to orient the spindle?  I gather the C-axis homes every time it's enabled (like my Fanuc), but I don't see the need for spindle orient once a C-axis is available.

And, looking back through NoJo and Andy Pugh's discussion while they were working out the bugs, resetting the encoder on C-axis enable results in the C-axis immediately homing. 

I think this takes place in caxis.comp.

Maybe.

well, the index iirc is used by c and spindle, for m19 etc.

I'll try to get to testing in near future, busy working on my slv40 mill currently.

resetting the encoder on C-axis enable results in the C-axis immediately homing.

As I see it the problem when switching from spindle mode back to rotary mode is to get the motor to match the commanded position of the rotary axis before the encoder was disconnected in the switch to spindle mode. If the commanded position does not match the encoder feedback a joint following error will occur when the encoder is reconnected. That is at least how I understand it.

Thus, in my opinion, just resetting the encoder count to the index is not enough since there is still a difference between the commanded position (which has not changed during spindle mode) and the newly reconnected encoder position simply because the motor is in a different position.
Using M19 in spindle mode seems the logical solution to orient the motor to where it was in rotary mode.
The question is, how accurate can the spindle be oriented using M19?
 

So it does seem that the caxis.comp is the component that I had remembered. Here is the whole saga, unfortunately the thread title is misleading:
forum.linuxcnc.org/10-advanced-configura...and?start=140#210682

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).