Re: NEW member Suitable conversions?

>
> From: Jon Elson <jmelson@...>
> "D.F.S." wrote:

Thanks to all who responded, I didn't reply to everyone just to keep
the volume of mail reasonable.

> The table motion should be called X and Y, and the glue dispensing
> head's motion should be Z.

Thanks.

> That will make it most compatible with software that will produce
> coordinates for the glue dots.

It is minor point, I was not clear on to begin with.
This thing WAS a glue dispenser.

I intend to use it as a general purpose light mill, and
to plot and drill circuit boards.

This is kind of a bootstrap type situation.
Building tools to build tools to build something else yet to be
determined. Maybe I'll never get to the building "Something" part ;-).

> > Does this sound reasonable?
> > Any red flags or problems at the outset on making something like this
> > work?
>
> No, it sounds fairly straightforward.

Good, I was hoping it would be.

> > This may be too general of a question, but how are such motors
> > "Usually" encoded to determine rotation?
>
> No specific type is 'usual'. There could be linear or rotary inductosyn
> transducers, rotary or linear
> optical encoders, or something else. The rotary type could be inside
> the motor, or external.
> There may also be a DC tachometer.

However they are encoded, it is internal to the motors,
I should have stated that.
The only thing on the ways are a dozen limit switches.

> > The motor controllers appear to be somewhat modular, and may be
> > usable seperate from the rest of the controller.
>
> Yes, except on the latest controls, the servo amps were pretty much
> separate
> modules, with very simple and pretty standard interfacing to the CNC.
> +/- 10 V analog DC was the most common standard for velocity command.

Great, I'll have to look into that.

> > How good would EMC be at running a lathe?
> > Everyone seems to be dealing in mills.
>
> Well, I'm pretty sure about 2 years ago, a turning center was set up
> with a much
> earlier version of EMC, and it DID do threading, so EMC knows how to
> handle a spindle encoder - or at least it still should.

> Other than that, the only difference is to be able to display the X
> position as radius or diameter, which could be completely handled
> in the user interface. Otherwise, there is no difference in the RS-274
> commands or the motion planning.
>
> One other thing, on electronically variable speed spindles you might
> want to have spindle speed controlled by X position, to maintain
> constant surface speed. That is not currently implemented, I don't
> think. It should not be hard, however.

I'll have to look into that.

The current motor only have 4 speeds, 900, 1800, 2700, 3600 if I recall.
it was clearly designed for carbide tools and small diam parts.

I do have a 7 HP DC motor I picked up with plans to use as a new spinde

motor, if necessary.

The part I'm still at a loss on, is how to do "Tool Changes".
With this type of lathe all the tools for a given project are bolted
down to the table.
(Lousy Ascii Art)
X
+----------------------X-----------------+
| X |
| XXXX Tool 1 Tool 4 |
| |
| |
|XXXX Tool 2 |
| |
| |
|XXXXXXXXXX Tool 3 (Drill) |
| |
| |
| X |
| XXXXX Tool 5 |
| |
+----------------------------------------+

How could the system intelligenty do a "Tool Change" without simply
making me do absolute positioning of the entire table based on presumed
tool location.

I'd like to be able to go back to an old G code file and make a new part
months later.
I REALLY like to be able to set the tooling up in about the same locations,
and recalibrate the system on a tool-by-tool basis, rather than trying to
bold every single tool back in an exact location down to the ten-thousanths
or have a new part that is out of whack.

Is this something the system can do with tool offsets? or is this more
complicated than that?

Marc