Re: [Emc-users] Lathe ATC integration

[Andy Pugh]

On 3 August 2010 13:20, Erik Christiansen  wrote:

> Oh ... yes, I forgot about aligning the INT30 dogs when inserting the
> toolholder. Still, that could at worst be done by running the spindle at
> inching speed over a springloaded toolholder until it engages the
> socket, as detected by a microswitch? (OK, that necessitates  a very good
> VFD.)

I think you can probably do that with any VFD. With a very good VFD
you could use the spindle encoder to accurately align the dogs before
trying.

> Do we need non-standard G-code in order to have the spindle serve
> alternatively as a rotary axis?

I can't say I have given it much thought, but a separate PID for
homing the dogs added to the normal spindle speed PWM demand would
probably work perfectly well.

-- 
atp

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Erik Christiansen]

On Tue, Aug 03, 2010 at 10:44:44AM +0100, Andy Pugh wrote:
> On 3 August 2010 09:41, Erik Christiansen  wrote:
> > On Mon, Aug 02, 2010 at 07:44:06PM +0100, Andy Pugh wrote:
> >> I can't help thinking that using a G-code routine (and, in fact,
> >> having the ATC defined as an axis) is sub-optimal.
> >
> > What's the basis for that Andy? The method seems to have worked well for
> > Schooner, and it sounds very appealing.
> 
> It seems rather like defining the spindle as a rotary axis. It would
> work, but would need non-standard G-code.

Oh ... yes, I forgot about aligning the INT30 dogs when inserting the
toolholder. Still, that could at worst be done by running the spindle at
inching speed over a springloaded toolholder until it engages the
socket, as detected by a microswitch? (OK, that necessitates  a very good
VFD.)

Do we need non-standard G-code in order to have the spindle serve
alternatively as a rotary axis? If M3/M4 were to also block spindle
encoder pulses from the rotary axis input, then there wouldn't be a
following error when it's just a spindle. M5 could again admit rotary
axis input, allowing gcode to drive the spindle as an axis. EMC2
wouldn't know that they are physically one.

After all, if the spindle can't at least rotate to a home, to align with
the toolholder, then the tool magazine becomes horribly complex, doesn't
it?

> In general M6 T4 should be all it takes to load T4. In Schooner's
> setup he needs to replace all the M6 TN lines with a  oldtool
> newtool (If I have read it correctly)
> Tool changes will happen very slowly if the max-velocity slider is set
> low. That also seems a bit wrong.

If I have physically set a manual velocity override, there seems little
basis for protesting that it works. Alternatively, if it's only intended
to operate when cutting, then, again, that could be masked by M5, in
hardware if necessary.

> > Even with gcode processing being single threaded, it'd work well
> > enough for me, I think, since there's not a lot of point moving XYZ
> > about until the new tool has been inserted. Unless, of course, the
> > tools merely sit in holders off the edge of the table, and
> > toolchange is handled by the existing axes.

> In the case of a rack-type toolchanger G-code looks like a more
> logical way to do it, but there is also some support for such
> toolchanges:
> http://wiki.linuxcnc.org/emcinfo.pl?RackToolChanger

Hmmm, I didn't find even a vestigial hint of what is intended there, but
looking at the patch, and finding generate_toolchange_move() in
STOP_SPINDLE_TURNING(), there seems to be scope for sufficient reverse
engineering to get some idea of what it is supposed to do.

How much state do we really need if a tool carousel is driven as a
rotary axis, with as few as one encoder pulses per tool position? If it
can home, and rotate in both directions, then we can keep track of the
current tool position in a gcode variable, and choose CW or ACW.

> > But fun though that would be, it seems hard to beat chucking out the M6
> > command and just hoofing about in a subroutine to change tool. It does
> > make gcode to  communication a bit of a doddle. ;-)
> 
> I am not entirely clear that that is how it works for Schooner. I have
> a feeling that he needs to call an  subroutine instead of using
> the M6 G-code. I might be wrong, perhaps M-words can be overloaded?

No, I also understand that the  subroutine replaces the M6 G-code
command in his case. In there he can move XYZ and or extra axes to
change tool, and return. A spare M[100-199]-code pair may perhaps be
used to operate e.g. your pneumatic tool grabber. 

> > And anything which obviates the need to use that ladder thing is worth
> > whatever it costs, and more, in my case.
> 
> I have managed to avoid it so far, though I am sure it is great when
> you are used to it.
> My approach would have been the HAL module written in comp that I
> half-wrote earlier in the thread, used in place of the
> hal_manualtoolchanger

Ah, yes, a bit of 'C' with clearly visible states would suit me right down
to the ground. Much easier for me to deal with than trying to ladderise
a state machine. It's 30 years since I touched relay logic, and I didn't
warm to it then. (Designing telecommunications systems with hundreds of
instances of large and small state machines quickly moves things beyond
relay logic.)

Erik

-- 
Truth decays into beauty, while beauty soon becomes merely charm. Charm
ends up as strangeness, and even that doesn't last, but up and down are
forever.   - The Laws of Physics


--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Emc-users mailing list
Emc-users@lis

Re: [Emc-users] Lathe ATC integration

[Andy Pugh]

On 3 August 2010 09:41, Erik Christiansen  wrote:
>
> On Mon, Aug 02, 2010 at 07:44:06PM +0100, Andy Pugh wrote:

>> I can't help thinking that using a G-code routine (and, in fact,
>> having the ATC defined as an axis) is sub-optimal.
>
> What's the basis for that Andy? The method seems to have worked well for
> Schooner, and it sounds very appealing.

It seems rather like defining the spindle as a rotary axis. It would
work, but would need non-standard G-code.

In general M6 T4 should be all it takes to load T4. In Schooner's
setup he needs to replace all the M6 TN lines with a  oldtool
newtool (If I have read it correctly)
Tool changes will happen very slowly if the max-velocity slider is set
low. That also seems a bit wrong.

> Even with gcode processing being
> single threaded, it'd work well enough for me, I think, since there's
> not a lot of point moving XYZ about until the new tool has been inserted.
> Unless, of course, the tools merely sit in holders off the edge of the
> table, and toolchange is handled by the existing axes.

In the case of a rack-type toolchanger G-code looks like a more
logical way to do it, but there is also some support for such
toolchanges:
http://wiki.linuxcnc.org/emcinfo.pl?RackToolChanger

> But fun though that would be, it seems hard to beat chucking out the M6
> command and just hoofing about in a subroutine to change tool. It does
> make gcode to  communication a bit of a doddle. ;-)

I am not entirely clear that that is how it works for Schooner. I have
a feeling that he needs to call an  subroutine instead of using
the M6 G-code. I might be wrong, perhaps M-words can be overloaded?

> And anything which obviates the need to use that ladder thing is worth
> whatever it costs, and more, in my case.

I have managed to avoid it so far, though I am sure it is great when
you are used to it.
My approach would have been the HAL module written in comp that I
half-wrote earlier in the thread, used in place of the
hal_manualtoolchanger


-- 
atp

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Erik Christiansen]

On Mon, Aug 02, 2010 at 07:44:06PM +0100, Andy Pugh wrote:
> On 2 August 2010 17:50, Schooner  wrote:
> 
> > I wrote a G Code sub routine called  which takes 2 parameters,
> > current_tool and required_tool.
> 
> > Using G Code overcomes all the problems of trying to move a previously
> > defined axis during a M6 command.
> 
> I can't help thinking that using a G-code routine (and, in fact,
> having the ATC defined as an axis) is sub-optimal.

What's the basis for that Andy? The method seems to have worked well for
Schooner, and it sounds very appealing. Even with gcode processing being
single threaded, it'd work well enough for me, I think, since there's
not a lot of point moving XYZ about until the new tool has been inserted.
Unless, of course, the tools merely sit in holders off the edge of the
table, and toolchange is handled by the existing axes. (Your pneumatic
grabber might then be the only mechanical component required, apart from
a tray with tapered tool receptacles.)

For a long time I had preferred a state machine solution, since it might
be an excuse to dust off my old code generator which produces
interacting communities of state machines, as complex as you like,
taking a (more readable) Structured English equivalent of ITUT SDL
(Specification and Description Language) as input. The Signals (events)
used in SDL have source & destination adresses, event_id, and one or
more parameters (so e.g. a tool_changer_detent event could carry a
tool_number parameter, if desired.)

But fun though that would be, it seems hard to beat chucking out the M6
command and just hoofing about in a subroutine to change tool. It does
make gcode to  communication a bit of a doddle. ;-)
If we have M5 also open a swarf-excluding lid over the tools, and wait
for an input to inform that the lid is open, then we can proceed to
change tools.

And anything which obviates the need to use that ladder thing is worth
whatever it costs, and more, in my case.

I'm trying to think of what's not to admire about Schooner's .
So far it looks an awful lot like a genuinely optimal solution, being
simple, elegant, effective, and eliminating superfluous add-on guff
which is just another nuisance to learn.

Now, with your great grabber, and Schooner's , I think ATC has moved
into the achievable realm with a whoosh!

Many thanks to you both.

Erik

-- 
Linux runs on 1.13 percent of desktops, 20.8 percent of servers, and on
91 percent of the world's 500 fastest supercomputers.
   - http://web.eweek.com/t?ctl=777CB:D3FDA57AA7175079D12B9A56271F01FD&;


--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Kirk Wallace]

On Mon, 2010-08-02 at 19:44 +0100, Andy Pugh wrote:
... snip
> I think that the comp file was the right approach. One useful and easy
> modification to that would have been a pin that could be linked to the
> X-axis homing state, so that it would do a full rotation while
> watching a micoswitch linked to a knob on the toolholder, so that it
> could determine which tool was loaded. (of course three switches/optos
> if you could spare the input pins would mean that it could always know
> the loaded tool)

My HNC lathe is like that, but with eight Hall sensors and a CMOS
priority encoder:
http://www.wallacecompany.com/cnc_lathe/HNC/00025-1a.jpg 
http://www.youtube.com/watch?v=vwhz3Ho_Gx0 

The Hall sensors allow the absolute encoder to work well in oily and/or
dirty environments. The CMOS chip(s) allow(s) up to 12 Volts, or more,
for the signals. This should be fairly easy to adapt to the EMCO type
changer. The HNC turret.comp currently scans for the matching tool
position, then engages the stop pawl. The comp could be modified to scan
for a tool position match, with stepgen is in velocity mode, then scan
for a zero (between positions) then back up against the EMCO's stop
finger for the Park state, then double check for the proper tool
position. With this there is no initialization to worry about and with
only eight positions the encoder is easy to make. My 24 position
carousel is a different story.
-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/index.html
California, USA


--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Andy Pugh]

On 2 August 2010 17:50, Schooner  wrote:

> I wrote a G Code sub routine called  which takes 2 parameters,
> current_tool and required_tool.

> Using G Code overcomes all the problems of trying to move a previously
> defined axis during a M6 command.

I can't help thinking that using a G-code routine (and, in fact,
having the ATC defined as an axis) is sub-optimal.

As you are using a homebrew HAL component, it might as well have an
output that goes directly to a stepgen input, with no need for that
stepgen to have anything at all to do with an axis.

I think that the comp file was the right approach. One useful and easy
modification to that would have been a pin that could be linked to the
X-axis homing state, so that it would do a full rotation while
watching a micoswitch linked to a knob on the toolholder, so that it
could determine which tool was loaded. (of course three switches/optos
if you could spare the input pins would mean that it could always know
the loaded tool)

-- 
atp

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Schooner]

Hi Again,

Just an update to the thread with the solution adopted.
I hate searching threads and never finding how it ended up being done.

I wrote a G Code sub routine called  which takes 2 parameters, 
current_tool and required_tool.
This is no problem, as when you do a tool change you will always know 
what tool you were using previously.
(often just tool1 from the initial machine homing)

This sub calculates the number of moves between tools, the number of 
units required for each move, based upon the
tuning of the A axis and the slightly differing distances between tool 
stations.

It moves the ATC forward to just past the required tool and reverses 
back to stall against the pawl.
Using G Code overcomes all the problems of trying to move a previously 
defined axis during a M6 command.

It then calls M6 Tx to match the required_tool.

I have linked a hal component I have called hal_autotoolupdate as per below.
*loadusr -W hal_autotoolupdate
net tool-change iocontrol.0.tool-change => hal_autotoolupdate.change
net tool-changed iocontrol.0.tool-changed <= hal_autotoolupdate.changed
net tool-number iocontrol.0.tool-prep-number => hal_autotoolupdate.number
net tool-oldnumber iocontrol.0.tool-number => hal_autotoolupdate.oldnumber
net tool-prepare-loopback iocontrol.0.tool-prepare => 
iocontrol.0.tool-prepared*


hal_autotoolupdate  is simply based on the hal_manualtoolchange python 
script, hacked to remove all the dialogs etc.

Since the tool change has already been done when M6 is called, all I 
want the component to do is pass a tool-changed signal
back without any operator input, so that the tool number and offsets are 
updated.

You could just feed one into another, as in the ..tool-prepare line, but 
I wanted the pins available for a pyvcp addition to my set up, to 
clearly display tool change and offset info.

This works perfectly and should work for any similar Boxford, Emco or 
whatever, that uses the same type of methodology for its ATC.

My lathe conversion  is now complete and fully functional.
I have learnt a lot on the way.

Thanks for the help and advice, particularly Andy Pugh for his help 
getting a threading pulse circuit working.
It cut a perfect 1.5mm pitch thread first time, simply using a tool at 
90deg to the workpiece.

regards

Arc Eye

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Andy Pugh]

On 29 July 2010 16:32, Schooner  wrote:

> Below is my idea of how I could achieve the tool change with a component
> and the associated .hal entries.

I have been thinking about this a bit, and your solution (not
unexpectedly) differs from mine.

One thing that I don't like about your approach is the usleep, I think
 it means that the component has to be userspace (which is probably
perfectly OK for a toolchanger). Realtime HAL components probably need
to run through to completion every time they are called.

I would write it as a state machine with an internal flag (the state
flag can even be a pin). This is off the top of my head (and I am not
really a C-programmer)



switch (state) {
case 0:
   if (toolchange) {
  state = 1;
  toolchange_finished = false;
  steps = tool_req - tool_sel;
  if (steps < 0)  steps = steps + 8 ;
  pos_out = pos_in + scale1 * steps;
   }
   returrn;
case 1:
if (pos_out - pos_in < 0.001) {
state = 3;
pos_out = pos_out - scale2;
}
return;
case 3:
if (pos_out - pos_in < 0.001) {
state = 0;
   toolchange_finished = true;
}
return;
default:
rtapi_print_msg(RTAPI_MSG_ERR, "Oh dear! /n");
}


-- 
atp

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Schooner]

Hi again

I have spent a few days reading all the manuals etc and studying the 
various links you all passed on.
I decided that Kirks solution of a component written in C was most 
viable for me.

In the interim I have written a G Code sub routine called m6 which does 
the tool change and I just have to do a M6Tx to get the tool number set 
correctly from the manual tool change module.
Gets me by for now.

Below is my idea of how I could achieve the tool change with a component 
and the associated .hal entries.

Before I start trying to test it, I would be grateful if you could run 
an eye over it and tell me if I am going in the right direction.
There could be an absolute howler in there and I currently am not far 
enough up the learning curve to know it.

Also, does EMC or Axis store the current tool number somewhere that can 
be read or will I have to implement some sort of .conf file to hold that 
very necessary data?
With no encoder etc, the whole operation hinges on knowing the start point.

regards

ArcEye



/***

## .hal entries

loadusr -W hal_ATC

net tool-change iocontrol.0.tool-change => hal_ATC.0.toolchange

net tool-changed iocontrol.0.tool-changed <= hal_ATC.0.toolchanged

net tool-number iocontrol.0.tool-prep-number => hal_ATC.0.toolnumber

net move-to stepgen.3.position-cmd <= hal_ATC.0.steps

# signal apos-fb already declared in .hal (net apos-fb 
stepgen.3.position-fb => axis.3.motor-pos-fb)

net apos-fb => hal_ATC.0.stepstaken

## unless need a tool-prepare signal this always connects straight back 
to tool-prepared ##

net tool-prepare-loopback iocontrol.0.tool-prepare => 
iocontrol.0.tool-prepared


/

/// ATC.comp

component ATC   "This component controls the Auto Tool Changer. M6 
calls this via net tool-change iocontrol.0.tool-change => 
hal_ATC.0.toolchange";
pin in bit toolchange   "Receives signal from M6 that tool change required";
pin in s32 toolnumber   "Receives Tx data from M6 (tool number 
requested) Only allows 1-8";
pin in s32 stepstaken   "Receives feedback from stepgen of position in 
commanded units";
pin out s32 steps "Sends number required, positive for forward and 
negative for backward, scale is 80 / mm on this setup";
pin out bit toolchanged "Sends signal when tool change finished";
param rw s32 currenttoolnumber  "Holds current position - get from file?";
function _;
license "GPL";
;;

FUNCTION(_)
{
int moves, index;
bool bEven, bToggle;

moves = index = 0;
bEven = bToggle = false;

//TODO get current tool number

if(toolchange)  // will receive input from stepgen.3.position-fb 
even when ATC jogged externally but no toolchange requested
{
if(toolnumber != currenttoolnumber && toolnumber > 0 && 
toolnumber < 9) // if a valid number
{
if(currenttoolnumber == 2 || currenttoolnumber == 4 || 
currenttoolnumber == 6 || currenttoolnumber == 8)
bEven = true;
if(currenttoolnumber < toolnumber)
moves = toolnumber - currenttoolnumber;
else
moves = (8 - currenttoolnumber) + toolnumber;

bToggle = bEven;

while(index < moves)
{
if(bToggle)
steps = (24 * 80);
else
steps = (22.2 * 80);
index++;
bToggle = !bToggle;
while(steps > stepstaken)
usleep(1000 * 1000);// wait for move to happen 
before next command
}
steps = (((moves / 2) + 1) * 80) * -1);// negative 
figure to lock back against pawl
}
toolchanged = 1;   // signal finished
}

//TODO set new tool number

}


--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Andy Pugh]

On 26 July 2010 04:40, Chris Morley  wrote:

> I wouldn't think this matters. Tool movement is relative not absolute.
> You ask the stepgen to move +130 from where ever you are, then -40
> till it hits a stop. The stop sets a new position and then you move relative 
> to
> that. The stepgen never needs to know the actual (absolute) position.

I am trying to work out if this could be done entirely in HAL.
The first problem I have found in the thought-experiment is deriving a
"initial rotation finished" signal. The rest seems reasonably
straightforward with arithmetic functions and mux components.

stepgen-cmd = stepgen-start + 100 * (new tool - old tool) + 30 is easy enough.

-- 
atp

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Schooner]

Hi again

Thanks for the various links and info, I will have to sit down and try to get 
my head around them and work out the best strategy

John and Steve are correct about the way it operates. 
It is a Boxford 240F and really it does not matter whether the motor loses 
steps when locking back.
The important thing is to know where the ATC is, ie locked back against a pawl 
on tool no X, not where the motor is.
The holding torque of the stepper is more than enough to ensure the ATC does 
not move once up against the pawl.

In Mach, I just set the tool number up to the current tool at startup.
Then the macro moved x amount for each tool position and having reached the 
required one, it moved back y amount to lock back against the pawl.
This worked fine, especially as the distance between each tool is not even, 
from cutting tool to drill is slightly shorter than drill to tool.
Odd to even moves were one amount and even to odd another.
360 degrees divided by 8 would have been too easy!

I could put an indexing switch by tool 1 and 'home' the ATC at startup.  This 
is the arrangement it had originally with a Fanuc control.
However that proximity switch and just about every other bit of low voltage 
stuff was burnt out, the control had suffered a power outrage.

Does EMC store the current tool number somewhere that can be read and written 
to, or will I have to implement that?

Thanks again, I'll see what I can come up with.

regards

ArcEye


> > I admit that I don't quite see how these tool changers are supposed to
> > work.  When the stepper backs up against the stop, doesn't it stall
> > and lose position?  Is there some kind of feedback available?  When
> > you start up, how do you know what position it's in?
> >
> > I have never seen a machine with a tool changer that operates like
> > this.
> >
>   
Boxford in UK used this for small and medium sized changers.

For an 8 position turret you have a ratchet with 8 teeth and a spring-loaded 
pawl. Assuming you know where you are now (say tool 2) and each click needs 
100 steps.

To move to tool 5 you output 330 steps. You now know that ratchet is about 
30 steps after a "click". Send 40 reverse steps. The stepper stalls, as you 
say, but you are in the known position for tool 5.  Next move to say tool 6 
just outputs 130 steps forward and 40 back.

John Prentice 

Sorry, but the pawl is essential to how it operates. 

The counter rotation is limited by the pawl to the
exact position where the tool should rest. These
tool turrets will only work with the spindle rotating
in the normal direction, pushing the tool back against
the pawl, but they do work well for such a simple
design. They were used by Southbend, Emco Maier,
and many others.

Steve Stallings 


--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Leslie Newell]

I really can't understand why they use a stepper for this task. There is 
no need for expensive stepper drivers and mucking about with allowing 
for lost pulses. A DC motor works easily as well if not better. Here is 
a video of an Emco conversion I did. 

All you need is a relay output and a simple encoder with one pulse per 
tool. With the relay off the motor is driven in reverse through a 
current limiting resistor. This holds the turret firmly in place against 
the pawl. With the relay energised it runs the motor at full power 
forwards. To change tool you work out how many tools you need to index 
then turn the relay on and count pulses from the encoder. When you reach 
the desired count, turn off the relay and it locks in place.  In the 
above conversion I used a simple hexagonal cam and a microswitch as the 
encoder.

If you want to do a really good job of it, add an index signal to find 
tool 1. At startup you rotate the turret until you see the index. I 
never bothered. I just set it up to remember the current tool number 
when you restart.

Les


On 26/07/10 02:27, Steve Stallings wrote:
> Sorry, but the pawl is essential to how it operates.
>
> The counter rotation is limited by the pawl to the
> exact position where the tool should rest. These
> tool turrets will only work with the spindle rotating
> in the normal direction, pushing the tool back against
> the pawl, but they do work well for such a simple
> design. They were used by Southbend, Emco Maier,
> and many others.
>
> Steve Stallings
>
>
>


--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Chris Morley]

> OK, that's kind of what I was afraid of.  Sounds like you need a
> position mode stepgen, so you can issue the particular number of steps
> you want.  But when you are done with your +130 and -40, your position
> mode stepgen doesn't know the position anymore because the motor has
> stalled.
> 
I wouldn't think this matters. Tool movement is relative not absolute.
You ask the stepgen to move +130 from where ever you are, then -40
till it hits a stop. The stop sets a new position and then you move relative to 
that. The stepgen never needs to know the actual (absolute) position.

There is a untested overly complicated example here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ClassicLadderExamples#Stepper_controller_tool_turret
this used sequential ladder (it didn't need to)
and is from an older version of CL that needed float pin conversion .


> The position commands for the next tool change would then have to be
> slipped by 10 steps worth of position to make up for the lossage
> (which you assume is 10 but probably isn't exactly.)

Not necessary. (I think)  see above. 

Chris M
 
  
_
MSN Dating: Find someone special. Start now.
http://go.microsoft.com/?linkid=9734384
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Steve Blackmore]

On Sun, 25 Jul 2010 18:32:40 -0500, you wrote:

>I don't know the physical requirements. If the pawl is not needed for
>rigidity but is only used for positioning then with an encoder the pawl can
>be removed.

The pawl and the and the worm gear work in combination are essential to
the rigidity. Without the pawl the stepper wouldn't stall and the
changer wouldn't! (reliably ;) The physical requirements, like anything
mechanical are the primary requirement.

It's a doddle to set on up in Mach3, it's a worm and wheel gearbox
driven by a stepper. Simple macro moves it forward x number of steps to
pass the pawl to the next approximate position. Direction reverses by a
few more steps than is needed to stall the stepper against the pawl and
the changer is locked. The worm and wheel takes the cutting load as the
pawl is spring loaded. There are NO switches or encoders.

System is 100% reliable under Mach - never figured out how to run it
under EMC.

Here's a link to my first prototype changer that I still use regularly.

http://www.youtube.com/watch?v=5dvLbb-HNsE

it now changes tools in under 2 seconds. ( Tool 1 to Tool 8).

Several changes have been made and the design is waiting for the Chinese
manufacturer to pull their finger out .

I have another changer. An expensive   fancy horizontal design, with
positional switches, that lifts, rotates, then descends to lock - it
only lasted days. Swarf got in it. It failed to lock. A few days later,
swarf got in again, this time it stopped in the wrong position and
sheared the central shaft. That was caused by having those positional
switches - it insisted it wasn't in the right position and destroyed
itself trying to get there. - It's now a $900 door stop, literally! It
hold my shop door open  - all it's fit for:)  

Steve Blackmore
--

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC Integration

[Ted Hyde]

emc-users-requ...@lists.sourceforge.net wrote:
> On 25 July 2010 14:53, Schooner  wrote:
>> >  The ATC is currently assigned to axis A, so I could just write GCode to
>> >  achieve the same result, but would rather it responded properly to M6.
>> >
>> >  Can anyone point me to some info or tell me the secret?!
>>  
ArcEye -

I have a 12-station turret running on my Tsugami Lathe as a pseudo-servo 
controlled joint - some ClassicLadder grabs the tool change request (Tx 
M6), runs the hydraulic locks, ensures the rest of the machine is in 
feed-hold, controls a PID component that is driving a small VFD that 
drives the AC induction motor that spins the turret. The VFD has a very 
quick accel/decel curve in it. I have an incremental encoder on the 
output of the gearbox (there is a high- and low- speed clutch as well as 
a brake on the turret gearbox) that reads about 180,000 pulses per full 
turret rotation. The index pulse on the encoder is ignored and generated 
by a separate inductive sensor on the turret itself, once per true 
revolution. The ladder is written to go directly to the tool number 
(hand-coded encoder position) as opposed to the "shortest distance"; 
thus if I'm at tool 12, and call tool 1 (which is right next to it 
physically), the turret will "unwind" all the way from 12 to 1 - which 
is not the fastest, but since it runs the change in high-speed for the 
majority of the time, I get a maximum tool change speed of about 3 to 4 
seconds; and for that I'm not going to complain about. The ladder shifts 
the gearbox into high for most of the transit, and downshifts for about 
one tool position; it reduces the "hunting" (since the VFD really isn't 
designed for that) to a minimum. The "joint" doesn't exist as an actual 
axis; so it isn't subject to modes or feed hold status of EMC. Homing is 
accomplished by button on startup (or any convenient time afterwards); 
it winds and unwinds the turret searching for the index pulse, then sets 
tool 1 ready for the first cutting operation. The index is ignored after 
that.
You can check out the entire process here at: 
http://www.casafrog.com/cfblog/ or the turret-specific pages starting 
around: http://www.casafrog.com/cfblog/?p=1214

Cheers,
Ted.

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Kirk Wallace]

If an encoder is being considered, this absolute encoder might be worth
a look:
http://www.avagotech.com/pages/en/motion_control_encoder_products/magnetic_encoders/aeat-6010/
 
(Short URL) http://alturl.com/aya7s 

I don't think the resolution is high enough for final tool position, but
certainly good enough for parking against a pawl. Being absolute, the
tool position is known even after rebooting.

Here is what I have on my site:
http://wallacecompany.com/machine_shop/EMC2/AEAT-6010/ 

-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/index.html
California, USA


--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Kirk Wallace]

On Sun, 2010-07-25 at 12:10 -0500, Chris Radek wrote:

I think the changer might be like this one:
http://www.youtube.com/watch?v=njRvzHUuL1I 

-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/index.html
California, USA


--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Steve Stallings]

Sorry, but the pawl is essential to how it operates. 

The counter rotation is limited by the pawl to the
exact position where the tool should rest. These
tool turrets will only work with the spindle rotating
in the normal direction, pushing the tool back against
the pawl, but they do work well for such a simple
design. They were used by Southbend, Emco Maier,
and many others.

Steve Stallings 

> -Original Message-
> From: Stuart Stevenson [mailto:stus...@gmail.com] 
> Sent: Sunday, July 25, 2010 6:33 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Lathe ATC integration
> 
> I don't know the physical requirements. If the pawl is not 
> needed for rigidity but is only used for positioning then 
> with an encoder the pawl can be removed.
> 
> On Sun, Jul 25, 2010 at 5:10 PM, Chris Radek 
>  wrote:
> 
> > On Sun, Jul 25, 2010 at 06:44:31PM +0100, John Prentice wrote:
> >
> > > For an 8 position turret you have a ratchet with 8 teeth and a
> > spring-loaded
> > > pawl. Assuming you know where you are now (say tool 2) and each 
> > > click
> > needs
> > > 100 steps.
> > >
> > > To move to tool 5 you output 330 steps. You now know that 
> ratchet is
> > about
> > > 30 steps after a "click". Send 40 reverse steps. The 
> stepper stalls, 
> > > as
> > you
> > > say, but you are in the known position for tool 5.  Next 
> move to say 
> > > tool
> > 6
> > > just outputs 130 steps forward and 40 back.
> >
> > OK, that's kind of what I was afraid of.  Sounds like you need a 
> > position mode stepgen, so you can issue the particular 
> number of steps 
> > you want.  But when you are done with your +130 and -40, 
> your position 
> > mode stepgen doesn't know the position anymore because the 
> motor has 
> > stalled.
> >
> > The position commands for the next tool change would then 
> have to be 
> > slipped by 10 steps worth of position to make up for the lossage 
> > (which you assume is 10 but probably isn't exactly.)
> >
> > I don't see a good way to do this with the stock stepgen.  Maybe a 
> > totally different component is needed.  You still have the 
> problem of 
> > not knowing what position it's in when you start up (or 
> even if it's 
> > in a valid position).  If it starts between positions, it won't 
> > correct itself.
> >
> > Now let me continue on with what I'd do in this position:
> >
> > If you add an encoder with index, all these problems are 
> solved.  Upon 
> > startup you can seek the index position.  Once you have 
> done that, you 
> > have exact position information forever, no matter what the stepper 
> > does.  You can use velocity mode stepgen then, and you know exactly 
> > when (at what position) you have to reverse to find the pawl.  You 
> > know whether the tool change has completed successfully because the 
> > turret will be in the correct position.
> >
> > Then the tool change procedure would look like:
> >
> > 1. If you have not yet found index this run, do that, then 
> continue on 
> > 2. Turn forward until the reversal position for the 
> requested tool 3. 
> > Turn backward until the lock position for the requested 
> tool 4. Tell 
> > stepgen to stop 5. If still at the lock position, report 
> that the tool 
> > change is OK
> >
> > Note that between 4 and 5, the stepgen will decelerate to a 
> stop, so 
> > extra steps will be issued.  If the pawl didn't lock for 
> some reason, 
> > step 5 will fail and you won't go on to crash with an 
> unlocked turret.
> >
> > While you can manage without feedback, I think adding it 
> would change 
> > this troubled design into a system that works reliably and safely.
> >
> > After typing all that I see that neither configuration is 
> going to be 
> > very simple to set up.
> >
> > Chris
> >
> >
> > 
> --
> >  This SF.net email is sponsored by Sprint What will you do 
> > first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> 
> 
> 
> --
> dos centavos
> --
> 

Re: [Emc-users] Lathe ATC integration

[Stuart Stevenson]

I don't know the physical requirements. If the pawl is not needed for
rigidity but is only used for positioning then with an encoder the pawl can
be removed.

On Sun, Jul 25, 2010 at 5:10 PM, Chris Radek  wrote:

> On Sun, Jul 25, 2010 at 06:44:31PM +0100, John Prentice wrote:
>
> > For an 8 position turret you have a ratchet with 8 teeth and a
> spring-loaded
> > pawl. Assuming you know where you are now (say tool 2) and each click
> needs
> > 100 steps.
> >
> > To move to tool 5 you output 330 steps. You now know that ratchet is
> about
> > 30 steps after a "click". Send 40 reverse steps. The stepper stalls, as
> you
> > say, but you are in the known position for tool 5.  Next move to say tool
> 6
> > just outputs 130 steps forward and 40 back.
>
> OK, that's kind of what I was afraid of.  Sounds like you need a
> position mode stepgen, so you can issue the particular number of steps
> you want.  But when you are done with your +130 and -40, your position
> mode stepgen doesn't know the position anymore because the motor has
> stalled.
>
> The position commands for the next tool change would then have to be
> slipped by 10 steps worth of position to make up for the lossage
> (which you assume is 10 but probably isn't exactly.)
>
> I don't see a good way to do this with the stock stepgen.  Maybe a
> totally different component is needed.  You still have the problem
> of not knowing what position it's in when you start up (or even if
> it's in a valid position).  If it starts between positions, it won't
> correct itself.
>
> Now let me continue on with what I'd do in this position:
>
> If you add an encoder with index, all these problems are solved.  Upon
> startup you can seek the index position.  Once you have done that, you
> have exact position information forever, no matter what the stepper
> does.  You can use velocity mode stepgen then, and you know exactly
> when (at what position) you have to reverse to find the pawl.  You
> know whether the tool change has completed successfully because the
> turret will be in the correct position.
>
> Then the tool change procedure would look like:
>
> 1. If you have not yet found index this run, do that, then continue on
> 2. Turn forward until the reversal position for the requested tool
> 3. Turn backward until the lock position for the requested tool
> 4. Tell stepgen to stop
> 5. If still at the lock position, report that the tool change is OK
>
> Note that between 4 and 5, the stepgen will decelerate to a stop, so
> extra steps will be issued.  If the pawl didn't lock for some reason,
> step 5 will fail and you won't go on to crash with an unlocked turret.
>
> While you can manage without feedback, I think adding it would change
> this troubled design into a system that works reliably and safely.
>
> After typing all that I see that neither configuration is going to be
> very simple to set up.
>
> Chris
>
>
> --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>



-- 
dos centavos
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Chris Radek]

On Sun, Jul 25, 2010 at 06:44:31PM +0100, John Prentice wrote:

> For an 8 position turret you have a ratchet with 8 teeth and a spring-loaded 
> pawl. Assuming you know where you are now (say tool 2) and each click needs 
> 100 steps.
> 
> To move to tool 5 you output 330 steps. You now know that ratchet is about 
> 30 steps after a "click". Send 40 reverse steps. The stepper stalls, as you 
> say, but you are in the known position for tool 5.  Next move to say tool 6 
> just outputs 130 steps forward and 40 back.

OK, that's kind of what I was afraid of.  Sounds like you need a
position mode stepgen, so you can issue the particular number of steps
you want.  But when you are done with your +130 and -40, your position
mode stepgen doesn't know the position anymore because the motor has
stalled.

The position commands for the next tool change would then have to be
slipped by 10 steps worth of position to make up for the lossage
(which you assume is 10 but probably isn't exactly.)

I don't see a good way to do this with the stock stepgen.  Maybe a
totally different component is needed.  You still have the problem
of not knowing what position it's in when you start up (or even if
it's in a valid position).  If it starts between positions, it won't
correct itself.

Now let me continue on with what I'd do in this position:

If you add an encoder with index, all these problems are solved.  Upon
startup you can seek the index position.  Once you have done that, you
have exact position information forever, no matter what the stepper
does.  You can use velocity mode stepgen then, and you know exactly
when (at what position) you have to reverse to find the pawl.  You
know whether the tool change has completed successfully because the
turret will be in the correct position.

Then the tool change procedure would look like:

1. If you have not yet found index this run, do that, then continue on
2. Turn forward until the reversal position for the requested tool
3. Turn backward until the lock position for the requested tool
4. Tell stepgen to stop
5. If still at the lock position, report that the tool change is OK

Note that between 4 and 5, the stepgen will decelerate to a stop, so
extra steps will be issued.  If the pawl didn't lock for some reason,
step 5 will fail and you won't go on to crash with an unlocked turret.

While you can manage without feedback, I think adding it would change
this troubled design into a system that works reliably and safely.

After typing all that I see that neither configuration is going to be
very simple to set up.

Chris

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[robert]

On 25/07/2010 20:14, Dave wrote:
> A separate Stepgen configured in Hal, setup in position mode, which is
> driven by Classic Ladder should work.
>

yep this is how i did one for someone else the other weekend its very 
crude what they did (this was a boxford) same changer as you are talking 
about,
classicladder talks to the stepgen and reads back postion
but its so very crude it can be pain some times. we are now adding an 
encoder onto the back of the turret to make life so much easyer and to 
know you deffently have the right tool.

rob

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Dave]

A separate Stepgen configured in Hal, setup in position mode, which is 
driven by Classic Ladder should work.

ClassicLadder can monitor hal pins set by an Mcode (you can access the 
M6 tool change hal pins via classic ladder and the hal configuration 
file)  and then respond by swinging the tool changer.
If the changer has some position feedback via Prox switches, etc. 
Classicladder could determine where it is and where it needs to go and 
then spin the step gen up or down to drive the stepper motor.

The ClassicLadder and Hal combination is very powerful and reliable.

Dave

On 7/25/2010 1:44 PM, John Prentice wrote:
> - Original Message -
> From: "Chris Radek"
> 
>
>> I admit that I don't quite see how these tool changers are supposed to
>> work.  When the stepper backs up against the stop, doesn't it stall
>> and lose position?  Is there some kind of feedback available?  When
>> you start up, how do you know what position it's in?
>>
>> I have never seen a machine with a tool changer that operates like
>> this.
>>
>>  
> Boxford in UK used this for small and medium sized changers.
>
> For an 8 position turret you have a ratchet with 8 teeth and a spring-loaded
> pawl. Assuming you know where you are now (say tool 2) and each click needs
> 100 steps.
>
> To move to tool 5 you output 330 steps. You now know that ratchet is about
> 30 steps after a "click". Send 40 reverse steps. The stepper stalls, as you
> say, but you are in the known position for tool 5.  Next move to say tool 6
> just outputs 130 steps forward and 40 back.
>
> John Prentice
>
>
>
>
> --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[John Prentice]

- Original Message - 
From: "Chris Radek" 

> I admit that I don't quite see how these tool changers are supposed to
> work.  When the stepper backs up against the stop, doesn't it stall
> and lose position?  Is there some kind of feedback available?  When
> you start up, how do you know what position it's in?
>
> I have never seen a machine with a tool changer that operates like
> this.
>
Boxford in UK used this for small and medium sized changers.

For an 8 position turret you have a ratchet with 8 teeth and a spring-loaded 
pawl. Assuming you know where you are now (say tool 2) and each click needs 
100 steps.

To move to tool 5 you output 330 steps. You now know that ratchet is about 
30 steps after a "click". Send 40 reverse steps. The stepper stalls, as you 
say, but you are in the known position for tool 5.  Next move to say tool 6 
just outputs 130 steps forward and 40 back.

John Prentice 




--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Chris Radek]

On Sun, Jul 25, 2010 at 05:11:19PM +0100, Andy Pugh wrote:

> Alternatively, you could do it all in G-code. (I think). Linking the
> tool-change pin to an MDI_COMMAND pin (see
> http://linuxcnc.org/docs/2.3/html/gui_halui.html#sub:MDI ) should
> allow you to execute a G-code subroutine automatically on M6. You
> would need to ensure that the subroutine sets a digital output true to
> indicate that it has finished, and link that to the tool-changed pin.

This won't work...

> The only issue I see is that I am not totally sure that MDI_COMMAND
> pins are active in auto-mode, and whether you are in Auto-mode during
> toolchange.

Yep for this reason.

I admit that I don't quite see how these tool changers are supposed to
work.  When the stepper backs up against the stop, doesn't it stall
and lose position?  Is there some kind of feedback available?  When
you start up, how do you know what position it's in?  

I have never seen a machine with a tool changer that operates like
this.

I think the only possible approach is to use an extra stepgen
component.  I guess maybe in velocity mode if the motor doesn't
maintain position?  But then how do you know how far it's moved?

Chris

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Andy Pugh]

On 25 July 2010 14:53, Schooner  wrote:

> The ATC is currently assigned to axis A, so I could just write GCode to
> achieve the same result, but would rather it responded properly to M6.
>
> Can anyone point me to some info or tell me the secret?!

Toolchanging seems to be generally done with some Classic Ladder code,
though I assume it could be done easily enough with a realtime or
userspace component created in comp.[1]

EMC sets the pin iocontrol.0.tool-change true when a toolchange is
requested by M6, and waits for the pin iocontrol.0.tool-changed to be
set true before continuing.

For an example using Classic Ladder see
http://wiki.linuxcnc.org/emcinfo.pl?ClassicLadderExamples
For documentation on writing a hal component in C that can do it see
http://linuxcnc.org/docs/html/hal_comp.html

Alternatively, you could do it all in G-code. (I think). Linking the
tool-change pin to an MDI_COMMAND pin (see
http://linuxcnc.org/docs/2.3/html/gui_halui.html#sub:MDI ) should
allow you to execute a G-code subroutine automatically on M6. You
would need to ensure that the subroutine sets a digital output true to
indicate that it has finished, and link that to the tool-changed pin.
The only issue I see is that I am not totally sure that MDI_COMMAND
pins are active in auto-mode, and whether you are in Auto-mode during
toolchange.

-- 
atp

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Lathe ATC integration

[Kirk Wallace]

On Sun, 2010-07-25 at 14:53 +0100, Schooner wrote:
> Hi Guys,
> 
> I have been searching the lists for info on setting up an ATC under EMC2.
> 
> I have found some references but nothing concrete as to how it is achieved.
> This must be quite a common requirement, but can see nothing in the 
> wikis etc about doing it.
> 
> I have an 8 station revolving tool changer, powered by a larger stepper 
> motor with a rachet and pawl arrangement to lock
> (go past pawl and reverse back against it to lock)
> I set this up simply in Mach, by writing a M6 macro, pity most other 
> things in Mach are so flaky.
> 
> Want to be able to code M6 T101 and have it turn until tool 1 is 
> selected etc.
> 
> The ATC is currently assigned to axis A, so I could just write GCode to 
> achieve the same result, but would rather it responded properly to M6.
> 
> Can anyone point me to some info or tell me the secret?!
> 
> thanks
> 
> ArcEye

There is some material here:
http://wiki.linuxcnc.org/emcinfo.pl?ToolChangerImplementation 

and here:
http://wiki.linuxcnc.org/emcinfo.pl?ClassicLadderExamples 

(but I know very little about Ladder)

The key point here is that the T and M6 words have a "wedge" in the .hal
setup. In your .hal file should be lines such as:
"...
net tool-prepare-loopback iocontrol.0.tool-prepare iocontrol.0.tool-prepared
net tool-change-start iocontrol.0.tool-change iocontrol.0.tool-prepared
..."

The prepare line connects the signal iocontrol.0.tool-prepare, which is
set true with a T word, to the signal iocontrol.0.tool-prepared your
tool change system needs to set true when the tool is in position. The
net command line shown above is the standard form for machines that
don't need a tool prepare function. The prepare signal is fed directly
to the prepared signal so EMC2 sees that the tool is prepared
immediately after a T word is invoked. For a carousel, the prepare
signal allows you to get the carousel ready for a tool change while the
old tool is still being used. For a turret, you will most likely need to
do the table rotation with the change signal, which in standard form
above, is connected directly to the changed signal. To set up your tool
changer the change/changed link needs to be broken and your change
routine inserted, such as:
"...
net tool-prepare-loopback iocontrol.0.tool-prepare => iocontrol.0.tool-prepared
net tool-change-start iocontrol.0.tool-change => myTurretComp.0.start
net tool-change-done myTurretComp.0.done => iocontrol.0.tool-changed
..."

You will need to create the change routine, using a HAL component,
Classic Ladder, or some other script. My lathe turret component
http://www.wallacecompany.com/cnc_lathe/HNC/emc2/turret.comp 

controls four digital output signals for position_change,
position_changed, seek, and stop, which raise the table, rotate it,
check for a position match, then stop rotation and part the table. A
tool position encoder is needed for this. Without a position encoder,
you will need to initialize the tool changer at start-up and tally the
position as you go. I think it should be fairly easy to add an encoder.
Realtime motion control is stalled during the M6 tool change, so the
motion component is not available to run the stepper, but I believe
stepgen still works, or you could use a PLC or microprocessor as a
signal generator.

There are a lot more details to this, but the above should get you
started.
-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/index.html
California, USA


--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Lathe ATC integration

[Schooner]

Hi Guys,

I have been searching the lists for info on setting up an ATC under EMC2.

I have found some references but nothing concrete as to how it is achieved.
This must be quite a common requirement, but can see nothing in the 
wikis etc about doing it.

I have an 8 station revolving tool changer, powered by a larger stepper 
motor with a rachet and pawl arrangement to lock
(go past pawl and reverse back against it to lock)
I set this up simply in Mach, by writing a M6 macro, pity most other 
things in Mach are so flaky.

Want to be able to code M6 T101 and have it turn until tool 1 is 
selected etc.

The ATC is currently assigned to axis A, so I could just write GCode to 
achieve the same result, but would rather it responded properly to M6.

Can anyone point me to some info or tell me the secret?!

thanks

ArcEye

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users