Dead CNC lathe -> EMC Special purpose machine

Starting backwards with the Mesa cards, I converted my Hardinge CHNC lathe and used a 5i20 with 7i33TA to drive the servos and two 7i37TA's for the I/O. Never had a bit of trouble that wasn't my fault for being dumb...

So your wanting to make cam like objects with a milling cutter on the X axis if I understand you correctly and using the spindle as the A axis. I've not done anything like that but I'm sure someone will chime in that has... I'm pretty sure that is not a problem to do.

John

Gregor wrote:

The lathe has a conventional geared headstock so the control would need to read the spindle encoder and move the X axis in sync, and feed the Z axis at feedrate. In other words, there would be no direct control over the spindle. I could install a spindle drive if necessary, but would prefer not to if possible. Essentially it would be a 2 controlled axis CNC slaved to the spindle.

I recall discussing this at some length either on the IRC channel or the mailing list (probably the former).

G33 looks at first glance like it would do what you want, but in fact I don't think it does.

How often do you need to change the profile? That question rather dictates how difficult it is.
If you don't need to load new profiles very often then a HAL component that reads in spindle position and outputs a radial offset to be added to the X-axis position is pretty easy. You would hard-code a lookup table in the component, compile it with "comp" and then wire it up in HAL and that would be pretty much that.

Recompiling the component with a new profile takes a minute or too, but is otherwise not at all onerous.

If you need to be able to change profiles often, and to have unskilled operators do it, then it gets a bit more troublesome. One solution might be a long column of pyvcp spinboxes, each individually net-ed to inputs of a HAL component, with the internal code interpolating between them. I am not sure how many points you need.

It has just occurred to me that, actually, for a simple oval shape, you only actually need one offset, and that could very easily be a pyvcp spinbox, and then all the calculations could possibly be done in HAL. (I was thinking that linear interpolation of radial positions would give a faceted finish, but that is just wrong, isn't it? )
Hal has no trigonometric functions (as far as I can see) , so you would need to make a custom component if you need anything other than linear intepolation, and there is a lot to be said for doing it as a hal component anyway. (you could easily make it automatically disable during homing, for example)

With a fast enough X-axis you could use a conventional turning tool to make the profile.

I want to try this now There is a fair-to-middling chance that the required Hal component will exist by this time tomorrow.

andypugh wrote:

I want to try this now There is a fair-to-middling chance that the required Hal component will exist by this time tomorrow.

Actually a bit sooner. It needs a tweak to pass fb-position back correctly to get following errors detected properly, but I have the cross-slide wiggling in synchrony with the spindle. I think that some cleverness will be needed to handle G0 moves during machining operations though.

I have now added the feedback and run a test, here is a video:



This is what the comp looks like:

component oval "Add a spindle-position related offset to an axis for oval turning";
pin in float encoder-pos "encoder position, should be scaled 0-1";
pin in bit disable "set high to disable, for example during homing";
pin in float pos-in "the input (axis position)";
pin in float offset "the required eccentricity";
pin out float pos-out "the modified position request";
pin in float fb-in "position feedback from joint";
pin out float fb-out "position feedback to motion";

function _ ;
license "GPL";
author "Andy Pugh";

;;

FUNCTION(_) {
static float profile[] =
{.500, .624, .741, .842, .922, .976, .999, .991, .952, .885, .794, .684,
.563, .437, .316, .206, .115, .048, .009, .001, .024, .078, .158, .259,
.376, .500, .624, .741, .842, .922, .976, .999, .991, .952, .885, .794,
.684, .563, .437, .316, .206, .115, .048, .009, .001, .024, .078, .158,
.259, .376, .500, .624,} ;
int i;
float f;

if (disable) {
pos_out = pos_in;
fb_out = fb_in;
return;
}
f = (encoder_pos - (int)(encoder_pos))*50.0;
i = f;
f = f-i;
pos_out = pos_in + offset*(profile + f * (profile[i+1]-profile));
fb_out = fb_in - (pos_out - pos_in);
}

Gregor wrote:

That said, I do understand what your code is doing (very clever BTW!) and I think it would suit my application very well. Am I correct in assuming that in your test that what we're looking at is a simple G1 Z move? And the X is programmed at nominal diameter with the actual position affected by the coefficients in your lookup table?

Yes, that is exactly right. It was actually running a loop with a return and an X increment, but in the video it is just a G1 Z-6 that is happening.

If I understand you right, that means that I can program any XZ profile as you would in normal turning, and the HAL component will automatically generate the cross sectional profile? I ask as there are chamfers and fillets at the ends of the elliptical section on the parts I'm making and it would be great if I could program it like a simple turned profile.

Yes. In fact with the component disabled, or with the eccentricity set to zero, the machine acts completely normally.

Are you doing anything else in your G code?

No. The eccentricity pin was connected to a pycvp spinbox control on the axis gui, purely for simplicity. It would be trivial to drive it from an M67 analogue output command, or even to link it to an axis, (you could create an XZU machine, for example) which would allow for blends and tapers.
Getting even more carried away, with a chain of the components in series you could mix them, blending from a 2 lobe to 3-lobe cam for example…

Being that I know nothing of how EMC works, is it possible to set the disable boolean in your component on the fly via a G or M code

Again, that would depend on how you set up the HAL file. It was my intention that the disable pin should be connected to the axis.is-homing pin so that the component didn't mess up homing moves. But it could easily be connected to a digital output (M62 - M65) or, in fact, to both with a HAL "OR2" block.

The component as presented was a proof of concept. It probably really ought to respect axis velocity and accelleration limits, and pass through the real position feedback so that exceeding the speed can trigger a following error.