Re: Auto tool changers (more)

Alan,

You're right.

For shortest path, use a geneva. Or the worm wheel and a brake/lock.
Or lever acting tapered shot pin, as used in turret lathe tailstocks.
Could be solenoid activated. As long as a solenoid is being
considered, it could "release" the pawl for "backwards" operation.

I'd use failsafe logic, as used in mill tool changers and lathe
spindle collets; i.e., the tool is held in position mechanically, and
the release force works against the mechanical device(s) holding the
tool in position to create the RELEASE (also like semi truck brakes).
This way, if the solenoid (or whatever) fails, the tool position will
be maintained. You just won't be able to index/remove it! (until you
correct the defective part)

Alan, you don't need anything like 20 degrees "fallback"! Plan for
MUCH less. Yes, the sherline rotary table would make an
excellent "model". You could pretty easily set up the pawl
arrangement on its face a la a "sacrificial" plate. The "shortest
path" is only needed for larger numbers of tools, IMO.

The simplest, though not fastest way to implement somethinng like
this for a control that doesn't know it exists is to use G04 (delay)
with the M06 (toolchange). Set the delay for "worst case" rotation
time. Even this assumes the M06 will at least have a "start process"
bit. If this is unavailable, use an AUX I/O output bit (which most
programs have) in the same block. Personally, I'd set it up for one
position index and repeat the I/O bit command as necessary to get the
tool I want.

Another way, that doesn't use ANY output bits is to program a motion
to a switch (use a subroutine; or cut and paste), such that the
motion trips the switch, causing the index. In this case, a PIC could
set a specific number of steps, and issue the needed motion profile,
answering back to ITSELF. Then, if the PIC is not satisfied that "all
is well", IT could trip a home or limit switch! Or be wired into an
opstop, or feedhold, or... you get the idea.

A similar, and even "lower tech", is to use a "canned routine"
(subroutine) motion which causes the index manually!

Sometimes we can look at how things were solved in the "mechanical
only" days, and use some updated version to accomplish what we need...
Not EVERYTHING needs to be computer controlled to be automatic!

Hope this helps.

Ballendo

P.S. With one input bit, or an output bit and a pic, we can
accomodate any number of tool positions on a turret; it just may not
be particularly fast, or efficient. But it MAY still beat "hand"
change-overs, and allow unattended (tho' watched<G>) operation

P.P.S. To allow for "loading" positions, just use a different number
of steps in another sub. (putting the setscrews in a favourable
position)

Does anybody besides me see a few "marketable products" here?!?!

--- In CAD_CAM_EDM_DRO@y..., Alan Marconett KM6VV <KM6VV@a...> wrote:
> Hi Bill, Ballendo,
>
> I've got the "two sensor" indexing scheme down from previous
projects
> (see previous posts). I am doubtful that the ratchet/paw mechanism
on
> the tool changer would allow reverse rotation for anything other
then
> "falling back" against the paw, and thus "shortest path", while
> interesting, may not be allowed.
>
> It sounds like there are only three positions; slots take three
tools,
> and holes take another three tools (boreing). Three positions are
thus
> needed, and Bill has suggested "tool loading" positions, which can
also
> be accomodated.
>
> Given the ammount of "over travel" needed, and the worm gear ratio,
I
> believe I can use a rotary table to simulate the action. So what
I'm
> looking for is a detailed plan, such as: From index, rotate 140
degrees,
> then fall back 20 degrees. How about videotape? Or a movie file?
>
> What driver will be used on the stepper motor? How many steps on
the
> motor? I have an Idea to send a DOS program, with the "canned" code
> needed to implement the actions. This would have a simple LPT port
> interface, which would later be used by the PIC based unit.
>
> How to interface to the controller program? Two bits out can code
three
> tool bit positions. The three "tool loading" positions would be
> selected from a pb on the electronics. The controller can wait for
the
> M6 line "tool change" before the part program is allowed to
continue. I
> KNOW how to get the needed three bits out of a program, but we need
to
> get them out of a controller program Bill (and others?) are going to
> USE. What controller program are you going to use Bill?
>
> Alan KM6VV
>