Here's a list of things I want to get from my mill. They all seem
individually doable. I can already use my mill for basic 3D
machining.

So, here's what I want.

1) All panel buttons and jog buttons work properly
2) Spindle Speed control from G code using solenoids that actuate the vari-drive
(and not VFD), so that I get full power output at all speeds, all the
while operating at 60 Hz
3) Flood and mist coolant working, including from G code
4) Jog mode, VFD at 5 Hz
5) 4th (rotary) axis based onthe Troyke CNC rotary table
6) Rigid tapping, based on synchronization to spindle speed (G33)

Once I do all of the above, I think that it wil be a Mercedes Benz
level mill, loaded with useful features, with everything accomplished
without modifying the hardware of this machine, and without incurring
expensive costs.

Am I missing anything in this picture?

i

Iggy,
I know this is fun. You have really done well and I am envious. I know this is a hobby and part of the hobby is increasing your
skill set, but those six goals cost your time and some money. Yeah, I know, spend to save, but those changes are impractical. I
suggest you step back, look at the bigger picture, establish a closure point and do another machine. My two cents.
Steve

"Ignoramus14749" wrote in message ...
Here's a list of things I want to get from my mill. They all seem
individually doable. I can already use my mill for basic 3D
machining.

So, here's what I want.

1) All panel buttons and jog buttons work properly
2) Spindle Speed control from G code using solenoids that actuate the vari-drive
(and not VFD), so that I get full power output at all speeds, all the
while operating at 60 Hz
3) Flood and mist coolant working, including from G code
4) Jog mode, VFD at 5 Hz
5) 4th (rotary) axis based onthe Troyke CNC rotary table
6) Rigid tapping, based on synchronization to spindle speed (G33)

Once I do all of the above, I think that it wil be a Mercedes Benz
level mill, loaded with useful features, with everything accomplished
without modifying the hardware of this machine, and without incurring
expensive costs.

Am I missing anything in this picture?

i

"Steve Lusardi"wrote...
Iggy,
I know this is fun. You have really done well and I am envious. I know
this is a hobby and part of the hobby is increasing your skill set, but
those six goals cost your time and some money. Yeah, I know, spend to
save, but those changes are impractical. I suggest you step back, look at
the bigger picture, establish a closure point and do another machine. My
two cents.
Steve


Hey, I'm with Iggy on this one - 1,3 and 4 are just parts of a proper VFD
and CNC installation?

2 and 6 sort of come together once you have a spindle encoder (maybe a
fine-resolution slotted opto?) and a few solenoids to work the vari-drive,
the rest is just programming and Iggy seems to have that cracked

No. 5, the rotary axis will take the machine's capabilities into a whole new
ballpark - need a custom gear wheel? program it. Need a custom splined
shaft? program it, etc. etc.

My two penn'orth,

Dave H.

On 2010-08-08, Steve Lusardi wrote:
Iggy,
I know this is fun. You have really done well and I am envious. I know this is a hobby and part of the hobby is increasing your
skill set, but those six goals cost your time and some money. Yeah, I know, spend to save, but those changes are impractical. I
suggest you step back, look at the bigger picture, establish a closure point and do another machine. My two cents.
Steve

Steve, the cost is really close to zero on these, speaking in
comparison the "newe prices"..

i

"Ignoramus14749" wrote in message ...
Here's a list of things I want to get from my mill. They all seem
individually doable. I can already use my mill for basic 3D
machining.

So, here's what I want.

1) All panel buttons and jog buttons work properly
2) Spindle Speed control from G code using solenoids that actuate the vari-drive
(and not VFD), so that I get full power output at all speeds, all the
while operating at 60 Hz
3) Flood and mist coolant working, including from G code
4) Jog mode, VFD at 5 Hz
5) 4th (rotary) axis based onthe Troyke CNC rotary table
6) Rigid tapping, based on synchronization to spindle speed (G33)

Once I do all of the above, I think that it wil be a Mercedes Benz
level mill, loaded with useful features, with everything accomplished
without modifying the hardware of this machine, and without incurring
expensive costs.

Am I missing anything in this picture?

i

Ignoramus14749 wrote:

Here's a list of things I want to get from my mill. They all seem
individually doable. I can already use my mill for basic 3D
machining.

So, here's what I want.

1) All panel buttons and jog buttons work properly

Noting but some wiring and EMC2 configuration here.

2) Spindle Speed control from G code using solenoids that actuate the vari-drive
(and not VFD), so that I get full power output at all speeds, all the
while operating at 60 Hz

You need to get your spindle encoder installed for this one since EMC2
will need to be able to measure the spindle RPM if it's going to control
the vari-drive. As long as someone has already written the modules to
control a vari-drive, the rest is just more wiring so EMC2 can control
the up/down solenoid valves (and VFD if you haven't already done that).

3) Flood and mist coolant working, including from G code

More wiring and EMC2 configuration. Nothing more than wiring up a couple
outputs to relays to control the coolant pump, and a solenoid valve for
mist.

4) Jog mode, VFD at 5 Hz

Wire up yet another output from EMC2 to your VFDs speed select input,
and program the VFD to select between 5 Hz and 60 Hz based on that. I
presume you'll also need to wire an output or outputs to control the
gear range shift mechanism.

5) 4th (rotary) axis based onthe Troyke CNC rotary table

Install your 4th axis drive, resolver converter, and a home switch on
the RT, and configure EMC2.

6) Rigid tapping, based on synchronization to spindle speed (G33)

This should come along with the spindle encoder you need for #2.


Once I do all of the above, I think that it wil be a Mercedes Benz
level mill, loaded with useful features,

More like a nice pickup with all the options. You'll see the "luxury"
mills and whatnot at IMTS.

with everything accomplished
without modifying the hardware of this machine,

Iggy, you ripped all the original controls out of the machine, that *is*
modifying the hardware of the machine.

and without incurring
expensive costs.

That's the important bit.


Am I missing anything in this picture?

Just the need to spend some time working with CAD and CAM software and
milling some wax to get familiar with them.

On 2010-08-08, Pete C. wrote:

Ignoramus14749 wrote:

Here's a list of things I want to get from my mill. They all seem
individually doable. I can already use my mill for basic 3D
machining.

So, here's what I want.

1) All panel buttons and jog buttons work properly

Noting but some wiring and EMC2 configuration here.

Yep.

2) Spindle Speed control from G code using solenoids that actuate the vari-drive
(and not VFD), so that I get full power output at all speeds, all the
while operating at 60 Hz

You need to get your spindle encoder installed for this one since EMC2
will need to be able to measure the spindle RPM if it's going to control
the vari-drive.


Correct. I will put an encoder on the spindle.


As long as someone has already written the modules to control a
vari-drive, the rest is just more wiring so EMC2 can control the
up/down solenoid valves (and VFD if you haven't already done that).

Yes, I think that it should work, it is simpoly a configuration issue
for EMC.

3) Flood and mist coolant working, including from G code

More wiring and EMC2 configuration. Nothing more than wiring up a couple
outputs to relays to control the coolant pump, and a solenoid valve for
mist.

Yes. I already have flood working 100% from G code, GUI or from
panel. Mist amounts to one more relay and a pneumatic valve.

4) Jog mode, VFD at 5 Hz

Wire up yet another output from EMC2 to your VFDs speed select input,
and program the VFD to select between 5 Hz and 60 Hz based on that. I
presume you'll also need to wire an output or outputs to control the
gear range shift mechanism.

Something like that. I may use an ADC for this (desired speed). It
would be at 10v or 1v dependong on what I want.

5) 4th (rotary) axis based onthe Troyke CNC rotary table

Install your 4th axis drive, resolver converter, and a home switch on
the RT, and configure EMC2.

Yep

6) Rigid tapping, based on synchronization to spindle speed (G33)

This should come along with the spindle encoder you need for #2.


Right-o!

Once I do all of the above, I think that it wil be a Mercedes Benz
level mill, loaded with useful features,

More like a nice pickup with all the options. You'll see the "luxury"
mills and whatnot at IMTS.

Correction taken.

with everything accomplished
without modifying the hardware of this machine,

Iggy, you ripped all the original controls out of the machine, that *is*
modifying the hardware of the machine.

TO me, modifying hardware is drilling new holes (except on the
enclosure) replacing moving parts etc

and without incurring
expensive costs.

That's the important bit.


Am I missing anything in this picture?

Just the need to spend some time working with CAD and CAM software and
milling some wax to get familiar with them.

I will start with plain G code at first.

i

On 2010-08-08, Dave H. wrote:

"Steve Lusardi"wrote...
Iggy,
I know this is fun. You have really done well and I am envious. I know
this is a hobby and part of the hobby is increasing your skill set, but
those six goals cost your time and some money. Yeah, I know, spend to
save, but those changes are impractical. I suggest you step back, look at
the bigger picture, establish a closure point and do another machine. My
two cents.
Steve


Hey, I'm with Iggy on this one - 1,3 and 4 are just parts of a proper VFD
and CNC installation?

2 and 6 sort of come together once you have a spindle encoder (maybe a
fine-resolution slotted opto?) and a few solenoids to work the vari-drive,
the rest is just programming and Iggy seems to have that cracked

No. 5, the rotary axis will take the machine's capabilities into a whole new
ballpark - need a custom gear wheel? program it. Need a custom splined
shaft? program it, etc. etc.

My two penn'orth,

This is what I think too.

i

Ignoramus2412 wrote:

As long as someone has already written the modules to control a
vari-drive, the rest is just more wiring so EMC2 can control the
up/down solenoid valves (and VFD if you haven't already done that).

Yes, I think that it should work, it is simpoly a configuration issue
for EMC.


Our older cnc lathes with gear boxes require a M41 or M42 command to switch gear ranges.
Perhaps you could implemnet something similar where the command emits an output you use to
shift the sheave. IRRC M41-44 are typical gear change M codes.

Wes

On 2010-08-08, Wes wrote:
Ignoramus2412 wrote:

As long as someone has already written the modules to control a
vari-drive, the rest is just more wiring so EMC2 can control the
up/down solenoid valves (and VFD if you haven't already done that).

Yes, I think that it should work, it is simpoly a configuration issue
for EMC.


Our older cnc lathes with gear boxes require a M41 or M42 command to switch gear ranges.
Perhaps you could implemnet something similar where the command emits an output you use to
shift the sheave. IRRC M41-44 are typical gear change M codes.

Wes, yes, I would like to find some good G code number and then
implement it. I got some suggestions on emc-users on how to do it,
with comparator elements of EMC. But speed change should only happen
during speed change, and not at any other moment, like reversal or
whatnot. If I get it to work, it will be much better than VFD, and
will let me tap with relatively larger taps.

i

Ignoramus2412 wrote:

Our older cnc lathes with gear boxes require a M41 or M42 command to switch gear ranges.
Perhaps you could implemnet something similar where the command emits an output you use to
shift the sheave. IRRC M41-44 are typical gear change M codes.

Wes, yes, I would like to find some good G code number and then
implement it. I got some suggestions on emc-users on how to do it,
with comparator elements of EMC. But speed change should only happen
during speed change, and not at any other moment, like reversal or
whatnot. If I get it to work, it will be much better than VFD, and
will let me tap with relatively larger taps.

I have a question, does your lathe have a back gear much like a manual Bridgeport? I've
never seen a mill like yours.

To some degree automating the sheave displacement should be lower on your list unless you
implement a tool changer. After all, you got to change a tool manually now, not much
effort to adjust the sheaves.

Are you planing a tool changer?

As far as keeping the varidrive, I went through a lot of effort to repair the varidrive on
my Clausing 6903 so I know where you are coming from. How hard my lathe can work is
limited by how hard I'm willing to push the thing.

Wes

On 2010-08-08, Wes wrote:
Ignoramus2412 wrote:

Our older cnc lathes with gear boxes require a M41 or M42 command to switch gear ranges.
Perhaps you could implemnet something similar where the command emits an output you use to
shift the sheave. IRRC M41-44 are typical gear change M codes.

Wes, yes, I would like to find some good G code number and then
implement it. I got some suggestions on emc-users on how to do it,
with comparator elements of EMC. But speed change should only happen
during speed change, and not at any other moment, like reversal or
whatnot. If I get it to work, it will be much better than VFD, and
will let me tap with relatively larger taps.

I have a question, does your lathe have a back gear much like a
manual Bridgeport? I've never seen a mill like yours.

My Clausing lathe does not have a back gear.

My Bridgeport Interact CNC mill does have a back gear, lowest it goes
is 60 RPM.

To some degree automating the sheave displacement should be lower on
your list unless you implement a tool changer. After all, you got
to change a tool manually now, not much effort to adjust the
sheaves.

Yes, but I could forget to change speed.

Are you planing a tool changer?

Definitely not, too complicated.

As far as keeping the varidrive, I went through a lot of effort to
repair the varidrive on my Clausing 6903 so I know where you are
coming from. How hard my lathe can work is limited by how hard I'm
willing to push the thing.

My own opinion, after the fact that I did it like you, is that it was
too much work and cost for not as much benefit. I did it
too. Varidrive on this mill, though, is workin well.

i

In article ,
Ignoramus2412 wrote:

On 2010-08-08, Wes wrote:
Ignoramus2412 wrote:

Our older cnc lathes with gear boxes require a M41 or M42 command to
switch gear ranges.
Perhaps you could implemnet something similar where the command emits an
output you use to
shift the sheave. IRRC M41-44 are typical gear change M codes.

Wes, yes, I would like to find some good G code number and then
implement it. I got some suggestions on emc-users on how to do it,
with comparator elements of EMC. But speed change should only happen
during speed change, and not at any other moment, like reversal or
whatnot. If I get it to work, it will be much better than VFD, and
will let me tap with relatively larger taps.

I have a question, does your lathe have a back gear much like a
manual Bridgeport? I've never seen a mill like yours.

My Clausing lathe does not have a back gear.

Really? I find this hard to believe.

Joe Gwinn

On 2010-08-09, Joseph Gwinn wrote:
In article ,
Ignoramus2412 wrote:

On 2010-08-08, Wes wrote:
Ignoramus2412 wrote:

Our older cnc lathes with gear boxes require a M41 or M42 command to
switch gear ranges.
Perhaps you could implemnet something similar where the command emits an
output you use to
shift the sheave. IRRC M41-44 are typical gear change M codes.

Wes, yes, I would like to find some good G code number and then
implement it. I got some suggestions on emc-users on how to do it,
with comparator elements of EMC. But speed change should only happen
during speed change, and not at any other moment, like reversal or
whatnot. If I get it to work, it will be much better than VFD, and
will let me tap with relatively larger taps.

I have a question, does your lathe have a back gear much like a
manual Bridgeport? I've never seen a mill like yours.

My Clausing lathe does not have a back gear.

Really? I find this hard to believe.

Joe Gwinn

Joe, I have a feeeling that I am wrong, but I am away from home.

I

On 2010-08-08, Ignoramus2412 wrote:
On 2010-08-08, Wes wrote:

[ ... ]

I have a question, does your lathe have a back gear much like a
manual Bridgeport? I've never seen a mill like yours.

My Clausing lathe does not have a back gear.

Which model of Clausing is this one? Mine has a back gear, as
does every other Clausing that I have seen. On most of the 12" swing
ones, it is a knurled knob which comes out of the front of the headstock
which you pull out, swing down (or up) and swing back in. But you also
have to open the cover over the belts and gears and pull out (until it
clicks) a pin coupling the bull gear (big one at the right of the
headstock) to the pulley sheaves. With the pin pressed in, the bull
gear is coupled to the pulley sheaves for "direct drive". With it
pulled out, the pulley sheaves rotate independently of the bull gear
(which rotates with the spindle nose). Then operating the lever engages
the back gear which is below the spindle instead of behind it as is
common for back gears. The small end of the back gear engages the bull
gear, and the large end of the back gear engages a gear on the other end
of the pulley sheaves. I think (without looking it up) that the ratio
is somewhere near 5:1.

My Bridgeport Interact CNC mill does have a back gear, lowest it goes
is 60 RPM.

To some degree automating the sheave displacement should be lower on
your list unless you implement a tool changer. After all, you got
to change a tool manually now, not much effort to adjust the
sheaves.

Yes, but I could forget to change speed.

If there is a back gear (my Bridgeport Series-I BOSS-3 has one)
Add a switch to sense the position of the back gear lever and have the
CNC sense that switch to see whether back gear is engaged. The computer
needs to know this anyway because the spindle reverses in back gear, and
you need to have the computer command the VFD for the opposite
direction in back gear.

And even without a back gear -- have the computer sense the
spindle speed to advise you to change the speed until you get it all
automated.

Are you planing a tool changer?

Definitely not, too complicated.

I would *like* to have one, but I agree. You would also have to
change the spindle to one which accepted the CAT/BT styles of tool
holders instead of the NTMB/NMTB (one of those is right. :-)

As far as keeping the varidrive, I went through a lot of effort to
repair the varidrive on my Clausing 6903 so I know where you are
coming from. How hard my lathe can work is limited by how hard I'm
willing to push the thing.

My own opinion, after the fact that I did it like you, is that it was
too much work and cost for not as much benefit. I did it
too. Varidrive on this mill, though, is workin well.

And as long as it is kept in good condition (replace the Delrin
bushings in the movable pulley halves, and the Delrin-covered steel key
which rides in a keyway in the motor spindle -- and I believe also in
the mill's spindle every so often.)

Enjoy,
DoN.

--
Remove oil spill source from e-mail
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Steve Lusardi wrote:
Iggy,
I know this is fun. You have really done well and I am envious. I know
this is a hobby and part of the hobby is increasing your skill set,
but those six goals cost your time and some money. Yeah, I know, spend
to save, but those changes are impractical. I suggest you step back,
look at the bigger picture, establish a closure point and do another
machine. My two cents.
Ummm, he's already done the hard stuff, most of this is REALLY easy,
just a few lines of HAL code to hook up most of this stuff!
REALLY!

The only thing that requires some work is adding an encoder to the
spindle. What the heck is impractical?
Jog on the VFD is just one more SSR connected to a terminal on the VFD.
Most of the mist vs flood is just a couple of SSRs that drive a solenoid
valve for mist and turn on the pump for flood. VERY easy, everything
except the actual SSR is already present in EMC. G33.1 rigid tapping is
already supported, too, and I have it on my Bridgeport as well. Works
like a charm! The spindle speed scheme to seek the right speed with the
air valves has already been done, I think, and just needs a little bit
of adapting to make it work. Iggy's a software guy, so this shouldn't
tax his abilities at all. Spindle braking by VFD is easy, it is just
setting some parameters in the VFD. Actuating the brake in the head is
just another air valve, and either rig it to a delay, so it engages the
brake a couple seconds after a spindle stop, or add a button to the
PyVCP (virtual control panel) to add a manual brake. Or, for the sole
purpose of locking the spindle for tool change, it could be a
manual-only button.

Jon

Ignoramus2412 wrote:

On 2010-08-08, Wes wrote:
Ignoramus2412 wrote:

As long as someone has already written the modules to control a
vari-drive, the rest is just more wiring so EMC2 can control the
up/down solenoid valves (and VFD if you haven't already done that).

Yes, I think that it should work, it is simpoly a configuration issue
for EMC.


Our older cnc lathes with gear boxes require a M41 or M42 command to switch gear ranges.
Perhaps you could implemnet something similar where the command emits an output you use to
shift the sheave. IRRC M41-44 are typical gear change M codes.

Wes, yes, I would like to find some good G code number and then
implement it. I got some suggestions on emc-users on how to do it,
with comparator elements of EMC. But speed change should only happen
during speed change, and not at any other moment, like reversal or
whatnot. If I get it to work, it will be much better than VFD, and
will let me tap with relatively larger taps.

i

You need to remember that there is a standard G-code, really S code to
set the speed of the spindle, and you implementation should properly
handle it. If the code says S1500, followed by M03, that should be all
that is required to start the spindle turning at 1,500 RPM. All the
code/script to start the spindle and adjust the vari-drive to the
correct speed needs to be hidden, so that there is nothing more than a
delay on the M03 while the spindle is brought to the correct speed,
before G-code execution continues.

The same can also apply to the high/low gear change, where the
background script can handle the high/low gear change transparently as
needed, i.e. set a threshold for the commanded RPM at which point the
high/low gear change occurs. There is no reason to have to add gear
changes to your G-code, when you already need special background
routines to handle the speed setting of the vari-drive.

On 2010-08-09, Pete C. wrote:

Ignoramus2412 wrote:

On 2010-08-08, Wes wrote:
Ignoramus2412 wrote:

As long as someone has already written the modules to control a
vari-drive, the rest is just more wiring so EMC2 can control the
up/down solenoid valves (and VFD if you haven't already done that).

Yes, I think that it should work, it is simpoly a configuration issue
for EMC.


Our older cnc lathes with gear boxes require a M41 or M42 command to switch gear ranges.
Perhaps you could implemnet something similar where the command emits an output you use to
shift the sheave. IRRC M41-44 are typical gear change M codes.

Wes, yes, I would like to find some good G code number and then
implement it. I got some suggestions on emc-users on how to do it,
with comparator elements of EMC. But speed change should only happen
during speed change, and not at any other moment, like reversal or
whatnot. If I get it to work, it will be much better than VFD, and
will let me tap with relatively larger taps.

i

You need to remember that there is a standard G-code, really S code to
set the speed of the spindle, and you implementation should properly
handle it. If the code says S1500, followed by M03, that should be all
that is required to start the spindle turning at 1,500 RPM. All the
code/script to start the spindle and adjust the vari-drive to the
correct speed needs to be hidden, so that there is nothing more than a
delay on the M03 while the spindle is brought to the correct speed,
before G-code execution continues.

The same can also apply to the high/low gear change, where the
background script can handle the high/low gear change transparently as
needed, i.e. set a threshold for the commanded RPM at which point the
high/low gear change occurs. There is no reason to have to add gear
changes to your G-code, when you already need special background
routines to handle the speed setting of the vari-drive.

PeteC, all I read about speed changes, makes it seem that it is
difficult to change speed by means of varidrive, within the regular
HAL logic.

However, I realized that it is a very easy way to do by means of
miscellaneous codes M100-199. Those codes are implemented in EMC by
means of scripts with ame names, living in a certain directory. Those
scripts. in turn, can get access to workings of EMC by means of
command "halcmd".

So, I wrote a speed change perl script. It is UNTESTED, because I am
away from home. But here it is.

It may be summarized as follows:

- if spindle is not running, start it and wait 1 second.
- calculate acceptable boundaries for actual speed.
- If speed is below acceptable boundary, turn on SPEED INCREASE
solenoid.
- If speed is above acceptable boundary, turn on SPEED DECREASE
solenoid.

- Assuming speed needed changing, wait up to 20 seconds until speed is
"in range".
- If after 20 seconds speed is in range, good, otherwise bad.

- if spindle was not running prior to this code, stop spindle and wait
until VFD stops is.

The advantage of this approach is that it is done in a totally self
evident script that can be debugged. The disadvantage is that S300
reads better than M141 P300. But I can live with it and leave S
command control VFD speed, which I do not really need to do with
varidrive that much, but just to look cleaner.

#!/usr/bin/perl

print STDERR "$0: " . join( ',', @ARGV ) . ".\n";

sub Kaput {
my ($msg) = @_;
die $msg;
}

sub get_hal {
my ($signal) = @_;
my $out = `halcmd getp $signal`;
chomp $out;
return $out;
}

sub set_hal {
my ($pin, $value) = @_;
system( "halcmd setp $pin $value" )
&& Kaput( "Could not halcmd $pin $value" );
}

my $P = $ARGV[0];
my $Q = $ARGV[1];

my $min_speed = 60;
my $max_speed = 4200;

my $min_delta = 5;
my $pct_delta = 0.05;
my $time_limit = 20; # seconds

my $commanded_speed = $P;

unless ( $min_speed = $commanded_speed && $commanded_speed = $max_speed ) {
die "Commanded speed $commanded_speed NOT between limits of $min_speed and $max_speed";
}

my $lower_limit = max( $min_speed, $commanded_speed * (1-$pct_delta) - $min_delta );
my $upper_limit = min( $max_speed, $commanded_speed * (1+$pct_delta) + $min_delta );
my $was_running = get_hal( 'motion.spindle-on' );

unless ( $was_running ) {
set_hal( "motion.spindle-forward", "TRUE" );
sleep 1;
}

my $start_time = time;
my $ok = undef;

my $speed = get_hal( 'motion.spindle-forward' );

my $increasing;
if ( $speed $lower_limit ) {
set_hal( 'halui.spindle.increase', 1 );
$increasing = 1;
} elsif ( $speed $upper_limit ) {
set_hal( 'halui.spindle.decrease', 1 );
$increasing = undef;
} else {
$ok = 1;
}

while( !$ok && time $start_time+$time_limit ) {
if ( $lower_limit = $speed && $speed = $upper_limit ) {
$ok = 1;
last;
}
sleep 0.01;
}

if ( $increasing ) {
set_hal( 'halui.spindle.increase', 0 );
} else {
set_hal( 'halui.spindle.decrease', 0 );
}

unless ( $ok ) {
# Stop spindle. We screwed up
set_hal( 'halui.spindle.is-on', 0 );
Kaput "Could not reach desired speed in $time_limit sec."
unless $ok;
}

unless ( $was_running ) {
# Spindle was not originally running, stop it
set_hal( 'halui.spindle.is-on', 0 );
}

exit 0;

Ignoramus2412 wrote:

On 2010-08-09, Pete C. wrote:

Ignoramus2412 wrote:

On 2010-08-08, Wes wrote:
Ignoramus2412 wrote:

As long as someone has already written the modules to control a
vari-drive, the rest is just more wiring so EMC2 can control the
up/down solenoid valves (and VFD if you haven't already done that).

Yes, I think that it should work, it is simpoly a configuration issue
for EMC.


Our older cnc lathes with gear boxes require a M41 or M42 command to switch gear ranges.
Perhaps you could implemnet something similar where the command emits an output you use to
shift the sheave. IRRC M41-44 are typical gear change M codes.

Wes, yes, I would like to find some good G code number and then
implement it. I got some suggestions on emc-users on how to do it,
with comparator elements of EMC. But speed change should only happen
during speed change, and not at any other moment, like reversal or
whatnot. If I get it to work, it will be much better than VFD, and
will let me tap with relatively larger taps.

i

You need to remember that there is a standard G-code, really S code to
set the speed of the spindle, and you implementation should properly
handle it. If the code says S1500, followed by M03, that should be all
that is required to start the spindle turning at 1,500 RPM. All the
code/script to start the spindle and adjust the vari-drive to the
correct speed needs to be hidden, so that there is nothing more than a
delay on the M03 while the spindle is brought to the correct speed,
before G-code execution continues.

The same can also apply to the high/low gear change, where the
background script can handle the high/low gear change transparently as
needed, i.e. set a threshold for the commanded RPM at which point the
high/low gear change occurs. There is no reason to have to add gear
changes to your G-code, when you already need special background
routines to handle the speed setting of the vari-drive.

PeteC, all I read about speed changes, makes it seem that it is
difficult to change speed by means of varidrive, within the regular
HAL logic.

However, I realized that it is a very easy way to do by means of
miscellaneous codes M100-199. Those codes are implemented in EMC by
means of scripts with ame names, living in a certain directory. Those
scripts. in turn, can get access to workings of EMC by means of
command "halcmd".

So, I wrote a speed change perl script. It is UNTESTED, because I am
away from home. But here it is.

It may be summarized as follows:

- if spindle is not running, start it and wait 1 second.
- calculate acceptable boundaries for actual speed.
- If speed is below acceptable boundary, turn on SPEED INCREASE
solenoid.
- If speed is above acceptable boundary, turn on SPEED DECREASE
solenoid.

- Assuming speed needed changing, wait up to 20 seconds until speed is
"in range".
- If after 20 seconds speed is in range, good, otherwise bad.

- if spindle was not running prior to this code, stop spindle and wait
until VFD stops is.

The advantage of this approach is that it is done in a totally self
evident script that can be debugged. The disadvantage is that S300
reads better than M141 P300. But I can live with it and leave S
command control VFD speed, which I do not really need to do with
varidrive that much, but just to look cleaner.

#!/usr/bin/perl

print STDERR "$0: " . join( ',', @ARGV ) . ".\n";

sub Kaput {
my ($msg) = @_;
die $msg;
}

sub get_hal {
my ($signal) = @_;
my $out = `halcmd getp $signal`;
chomp $out;
return $out;
}

sub set_hal {
my ($pin, $value) = @_;
system( "halcmd setp $pin $value" )
&& Kaput( "Could not halcmd $pin $value" );
}

my $P = $ARGV[0];
my $Q = $ARGV[1];

my $min_speed = 60;
my $max_speed = 4200;

my $min_delta = 5;
my $pct_delta = 0.05;
my $time_limit = 20; # seconds

my $commanded_speed = $P;

unless ( $min_speed = $commanded_speed && $commanded_speed = $max_speed ) {
die "Commanded speed $commanded_speed NOT between limits of $min_speed and $max_speed";
}

my $lower_limit = max( $min_speed, $commanded_speed * (1-$pct_delta) - $min_delta );
my $upper_limit = min( $max_speed, $commanded_speed * (1+$pct_delta) + $min_delta );
my $was_running = get_hal( 'motion.spindle-on' );

unless ( $was_running ) {
set_hal( "motion.spindle-forward", "TRUE" );
sleep 1;
}

my $start_time = time;
my $ok = undef;

my $speed = get_hal( 'motion.spindle-forward' );

my $increasing;
if ( $speed $lower_limit ) {
set_hal( 'halui.spindle.increase', 1 );
$increasing = 1;
} elsif ( $speed $upper_limit ) {
set_hal( 'halui.spindle.decrease', 1 );
$increasing = undef;
} else {
$ok = 1;
}

while( !$ok && time $start_time+$time_limit ) {
if ( $lower_limit = $speed && $speed = $upper_limit ) {
$ok = 1;
last;
}
sleep 0.01;
}

if ( $increasing ) {
set_hal( 'halui.spindle.increase', 0 );
} else {
set_hal( 'halui.spindle.decrease', 0 );
}

unless ( $ok ) {
# Stop spindle. We screwed up
set_hal( 'halui.spindle.is-on', 0 );
Kaput "Could not reach desired speed in $time_limit sec."
unless $ok;
}

unless ( $was_running ) {
# Spindle was not originally running, stop it
set_hal( 'halui.spindle.is-on', 0 );
}

exit 0;

I suspect your code will need some tweaking to account for lag time in
vari-drive response so it doesn't overshoot the target speed, i.e. only
turn on the up/down solenoid for 1 second, then turn it off and wait a
second for the drive to stabilize before checking the speed and
determining if it needs more adjustment.

There must be a way to hang this code off of the normal M03/M04 commands
so that the machine will operate more or less normally relative to other
CNC mills other than a bit slow spindle start when changing speeds. I
can't imagine that EMC2 has a limitation that would prevent this.

On 2010-08-09, Pete C. wrote:

Ignoramus2412 wrote:

On 2010-08-09, Pete C. wrote:

Ignoramus2412 wrote:

On 2010-08-08, Wes wrote:
Ignoramus2412 wrote:

As long as someone has already written the modules to control a
vari-drive, the rest is just more wiring so EMC2 can control the
up/down solenoid valves (and VFD if you haven't already done that).

Yes, I think that it should work, it is simpoly a configuration issue
for EMC.


Our older cnc lathes with gear boxes require a M41 or M42 command to switch gear ranges.
Perhaps you could implemnet something similar where the command emits an output you use to
shift the sheave. IRRC M41-44 are typical gear change M codes.

Wes, yes, I would like to find some good G code number and then
implement it. I got some suggestions on emc-users on how to do it,
with comparator elements of EMC. But speed change should only happen
during speed change, and not at any other moment, like reversal or
whatnot. If I get it to work, it will be much better than VFD, and
will let me tap with relatively larger taps.

i

You need to remember that there is a standard G-code, really S code to
set the speed of the spindle, and you implementation should properly
handle it. If the code says S1500, followed by M03, that should be all
that is required to start the spindle turning at 1,500 RPM. All the
code/script to start the spindle and adjust the vari-drive to the
correct speed needs to be hidden, so that there is nothing more than a
delay on the M03 while the spindle is brought to the correct speed,
before G-code execution continues.

The same can also apply to the high/low gear change, where the
background script can handle the high/low gear change transparently as
needed, i.e. set a threshold for the commanded RPM at which point the
high/low gear change occurs. There is no reason to have to add gear
changes to your G-code, when you already need special background
routines to handle the speed setting of the vari-drive.

PeteC, all I read about speed changes, makes it seem that it is
difficult to change speed by means of varidrive, within the regular
HAL logic.

However, I realized that it is a very easy way to do by means of
miscellaneous codes M100-199. Those codes are implemented in EMC by
means of scripts with ame names, living in a certain directory. Those
scripts. in turn, can get access to workings of EMC by means of
command "halcmd".

So, I wrote a speed change perl script. It is UNTESTED, because I am
away from home. But here it is.

It may be summarized as follows:

- if spindle is not running, start it and wait 1 second.
- calculate acceptable boundaries for actual speed.
- If speed is below acceptable boundary, turn on SPEED INCREASE
solenoid.
- If speed is above acceptable boundary, turn on SPEED DECREASE
solenoid.

- Assuming speed needed changing, wait up to 20 seconds until speed is
"in range".
- If after 20 seconds speed is in range, good, otherwise bad.

- if spindle was not running prior to this code, stop spindle and wait
until VFD stops is.

The advantage of this approach is that it is done in a totally self
evident script that can be debugged. The disadvantage is that S300
reads better than M141 P300. But I can live with it and leave S
command control VFD speed, which I do not really need to do with
varidrive that much, but just to look cleaner.

#!/usr/bin/perl

print STDERR "$0: " . join( ',', @ARGV ) . ".\n";

sub Kaput {
my ($msg) = @_;
die $msg;
}

sub get_hal {
my ($signal) = @_;
my $out = `halcmd getp $signal`;
chomp $out;
return $out;
}

sub set_hal {
my ($pin, $value) = @_;
system( "halcmd setp $pin $value" )
&& Kaput( "Could not halcmd $pin $value" );
}

my $P = $ARGV[0];
my $Q = $ARGV[1];

my $min_speed = 60;
my $max_speed = 4200;

my $min_delta = 5;
my $pct_delta = 0.05;
my $time_limit = 20; # seconds

my $commanded_speed = $P;

unless ( $min_speed = $commanded_speed && $commanded_speed = $max_speed ) {
die "Commanded speed $commanded_speed NOT between limits of $min_speed and $max_speed";
}

my $lower_limit = max( $min_speed, $commanded_speed * (1-$pct_delta) - $min_delta );
my $upper_limit = min( $max_speed, $commanded_speed * (1+$pct_delta) + $min_delta );
my $was_running = get_hal( 'motion.spindle-on' );

unless ( $was_running ) {
set_hal( "motion.spindle-forward", "TRUE" );
sleep 1;
}

my $start_time = time;
my $ok = undef;

my $speed = get_hal( 'motion.spindle-forward' );

my $increasing;
if ( $speed $lower_limit ) {
set_hal( 'halui.spindle.increase', 1 );
$increasing = 1;
} elsif ( $speed $upper_limit ) {
set_hal( 'halui.spindle.decrease', 1 );
$increasing = undef;
} else {
$ok = 1;
}

while( !$ok && time $start_time+$time_limit ) {
if ( $lower_limit = $speed && $speed = $upper_limit ) {
$ok = 1;
last;
}
sleep 0.01;
}

if ( $increasing ) {
set_hal( 'halui.spindle.increase', 0 );
} else {
set_hal( 'halui.spindle.decrease', 0 );
}

unless ( $ok ) {
# Stop spindle. We screwed up
set_hal( 'halui.spindle.is-on', 0 );
Kaput "Could not reach desired speed in $time_limit sec."
unless $ok;
}

unless ( $was_running ) {
# Spindle was not originally running, stop it
set_hal( 'halui.spindle.is-on', 0 );
}

exit 0;

I suspect your code will need some tweaking to account for lag time in
vari-drive response so it doesn't overshoot the target speed, i.e. only
turn on the up/down solenoid for 1 second, then turn it off and wait a
second for the drive to stabilize before checking the speed and
determining if it needs more adjustment.

There must be a way to hang this code off of the normal M03/M04 commands
so that the machine will operate more or less normally relative to other
CNC mills other than a bit slow spindle start when changing speeds. I
can't imagine that EMC2 has a limitation that would prevent this.

Pete, I am not speaking from any kind of knowledge. I think that I
found way to change spindle speed that I understand. There may be a
cuter aproach that I do not yet know. But I found something that I
personally find workable.

i

Ignoramus29207 wrote:

On 2010-08-09, Pete C. wrote:

Ignoramus2412 wrote:

On 2010-08-09, Pete C. wrote:

Ignoramus2412 wrote:

On 2010-08-08, Wes wrote:
Ignoramus2412 wrote:

As long as someone has already written the modules to control a
vari-drive, the rest is just more wiring so EMC2 can control the
up/down solenoid valves (and VFD if you haven't already done that).

Yes, I think that it should work, it is simpoly a configuration issue
for EMC.


Our older cnc lathes with gear boxes require a M41 or M42 command to switch gear ranges.
Perhaps you could implemnet something similar where the command emits an output you use to
shift the sheave. IRRC M41-44 are typical gear change M codes.

Wes, yes, I would like to find some good G code number and then
implement it. I got some suggestions on emc-users on how to do it,
with comparator elements of EMC. But speed change should only happen
during speed change, and not at any other moment, like reversal or
whatnot. If I get it to work, it will be much better than VFD, and
will let me tap with relatively larger taps.

i

You need to remember that there is a standard G-code, really S code to
set the speed of the spindle, and you implementation should properly
handle it. If the code says S1500, followed by M03, that should be all
that is required to start the spindle turning at 1,500 RPM. All the
code/script to start the spindle and adjust the vari-drive to the
correct speed needs to be hidden, so that there is nothing more than a
delay on the M03 while the spindle is brought to the correct speed,
before G-code execution continues.

The same can also apply to the high/low gear change, where the
background script can handle the high/low gear change transparently as
needed, i.e. set a threshold for the commanded RPM at which point the
high/low gear change occurs. There is no reason to have to add gear
changes to your G-code, when you already need special background
routines to handle the speed setting of the vari-drive.

PeteC, all I read about speed changes, makes it seem that it is
difficult to change speed by means of varidrive, within the regular
HAL logic.

However, I realized that it is a very easy way to do by means of
miscellaneous codes M100-199. Those codes are implemented in EMC by
means of scripts with ame names, living in a certain directory. Those
scripts. in turn, can get access to workings of EMC by means of
command "halcmd".

So, I wrote a speed change perl script. It is UNTESTED, because I am
away from home. But here it is.

It may be summarized as follows:

- if spindle is not running, start it and wait 1 second.
- calculate acceptable boundaries for actual speed.
- If speed is below acceptable boundary, turn on SPEED INCREASE
solenoid.
- If speed is above acceptable boundary, turn on SPEED DECREASE
solenoid.

- Assuming speed needed changing, wait up to 20 seconds until speed is
"in range".
- If after 20 seconds speed is in range, good, otherwise bad.

- if spindle was not running prior to this code, stop spindle and wait
until VFD stops is.

The advantage of this approach is that it is done in a totally self
evident script that can be debugged. The disadvantage is that S300
reads better than M141 P300. But I can live with it and leave S
command control VFD speed, which I do not really need to do with
varidrive that much, but just to look cleaner.

#!/usr/bin/perl

print STDERR "$0: " . join( ',', @ARGV ) . ".\n";

sub Kaput {
my ($msg) = @_;
die $msg;
}

sub get_hal {
my ($signal) = @_;
my $out = `halcmd getp $signal`;
chomp $out;
return $out;
}

sub set_hal {
my ($pin, $value) = @_;
system( "halcmd setp $pin $value" )
&& Kaput( "Could not halcmd $pin $value" );
}

my $P = $ARGV[0];
my $Q = $ARGV[1];

my $min_speed = 60;
my $max_speed = 4200;

my $min_delta = 5;
my $pct_delta = 0.05;
my $time_limit = 20; # seconds

my $commanded_speed = $P;

unless ( $min_speed = $commanded_speed && $commanded_speed = $max_speed ) {
die "Commanded speed $commanded_speed NOT between limits of $min_speed and $max_speed";
}

my $lower_limit = max( $min_speed, $commanded_speed * (1-$pct_delta) - $min_delta );
my $upper_limit = min( $max_speed, $commanded_speed * (1+$pct_delta) + $min_delta );
my $was_running = get_hal( 'motion.spindle-on' );

unless ( $was_running ) {
set_hal( "motion.spindle-forward", "TRUE" );
sleep 1;
}

my $start_time = time;
my $ok = undef;

my $speed = get_hal( 'motion.spindle-forward' );

my $increasing;
if ( $speed $lower_limit ) {
set_hal( 'halui.spindle.increase', 1 );
$increasing = 1;
} elsif ( $speed $upper_limit ) {
set_hal( 'halui.spindle.decrease', 1 );
$increasing = undef;
} else {
$ok = 1;
}

while( !$ok && time $start_time+$time_limit ) {
if ( $lower_limit = $speed && $speed = $upper_limit ) {
$ok = 1;
last;
}
sleep 0.01;
}

if ( $increasing ) {
set_hal( 'halui.spindle.increase', 0 );
} else {
set_hal( 'halui.spindle.decrease', 0 );
}

unless ( $ok ) {
# Stop spindle. We screwed up
set_hal( 'halui.spindle.is-on', 0 );
Kaput "Could not reach desired speed in $time_limit sec."
unless $ok;
}

unless ( $was_running ) {
# Spindle was not originally running, stop it
set_hal( 'halui.spindle.is-on', 0 );
}

exit 0;

I suspect your code will need some tweaking to account for lag time in
vari-drive response so it doesn't overshoot the target speed, i.e. only
turn on the up/down solenoid for 1 second, then turn it off and wait a
second for the drive to stabilize before checking the speed and
determining if it needs more adjustment.

There must be a way to hang this code off of the normal M03/M04 commands
so that the machine will operate more or less normally relative to other
CNC mills other than a bit slow spindle start when changing speeds. I
can't imagine that EMC2 has a limitation that would prevent this.

Pete, I am not speaking from any kind of knowledge. I think that I
found way to change spindle speed that I understand. There may be a
cuter aproach that I do not yet know. But I found something that I
personally find workable.

i

Jon seems to think someone else has already done this, I'd try to find
more information on that.

On 2010-08-09, Jon Elson wrote:
Steve Lusardi wrote:
Iggy,
I know this is fun. You have really done well and I am envious. I know
this is a hobby and part of the hobby is increasing your skill set,
but those six goals cost your time and some money. Yeah, I know, spend
to save, but those changes are impractical. I suggest you step back,
look at the bigger picture, establish a closure point and do another
machine. My two cents.
Ummm, he's already done the hard stuff, most of this is REALLY easy,
just a few lines of HAL code to hook up most of this stuff!
REALLY!

Yep, most of these new improvements involve routing wires properly
and writing configs and commands.

The "hard stuff", however, involved more of same. The whole project
was not mechanically challenging, it was mostly about learning how to
use various functions and connecting wires and cables. It was
complicated, but required no big physical efforts or mechanical
knowledge.

The only thing that requires some work is adding an encoder to the
spindle. What the heck is impractical?

I agree.

Jog on the VFD is just one more SSR connected to a terminal on the VFD.
Most of the mist vs flood is just a couple of SSRs that drive a solenoid
valve for mist and turn on the pump for flood. VERY easy, everything
except the actual SSR is already present in EMC. G33.1 rigid tapping is
already supported, too, and I have it on my Bridgeport as well. Works
like a charm!

Jon, practically speaking, how fast do you run your spindle when rigid
tapping with small taps?

Say you are tapping with 10-32 taps, how fast would you run your
spindle.

The spindle speed scheme to seek the right speed with the
air valves has already been done, I think, and just needs a little bit
of adapting to make it work. Iggy's a software guy, so this shouldn't
tax his abilities at all. Spindle braking by VFD is easy, it is just
setting some parameters in the VFD. Actuating the brake in the head is
just another air valve, and either rig it to a delay, so it engages the
brake a couple seconds after a spindle stop, or add a button to the
PyVCP (virtual control panel) to add a manual brake. Or, for the sole
purpose of locking the spindle for tool change, it could be a
manual-only button.

It should be a manual button, I think, I have not yet figured it
out. I thought about it last night, all the delays etc, it was
painful to think about. This is also a somewhat riskier function to
debug (compared to, say, flood), because of how a brake may fight the
VFD.

I have to look at the brake fuction more closely.

My current thinking about the brake is that the pneumatic system is
already made, such that that the brake engages with a delay, but
withdraws instantly. If so, then, the built in delay may be sufficient
to let the VFD stop the spindle.

I recently put a brake resistor on the VFD, and can stop faster than I
used to.

i

On 2010-08-09, Pete C. wrote:
I suspect your code will need some tweaking to account for lag time in
vari-drive response so it doesn't overshoot the target speed, i.e. only
turn on the up/down solenoid for 1 second, then turn it off and wait a
second for the drive to stabilize before checking the speed and
determining if it needs more adjustment.

There must be a way to hang this code off of the normal M03/M04 commands
so that the machine will operate more or less normally relative to other
CNC mills other than a bit slow spindle start when changing speeds. I
can't imagine that EMC2 has a limitation that would prevent this.

Pete, I am not speaking from any kind of knowledge. I think that I
found way to change spindle speed that I understand. There may be a
cuter aproach that I do not yet know. But I found something that I
personally find workable.

i

Jon seems to think someone else has already done this, I'd try to find
more information on that.

People did closed loop speed control with a VFD. I saw that. I have
not seen implementations of speed control with a varidrive. And I did
ask on the emc-users list.

This vari-drive control from G code is relatively rare, so I am not
surprised. Most modern VMCs simply have oversized spindle motors and
VFDs, whereas most older CNC and retrofit mills do not have pneumatic
varidrive control.

What I will do is, the S instruction will control VFD (S1000 == 60
Hz), and practically I will not use it much. And my M141 instruction
will adjust the varidrive whenever I see fit. Normally there is rarely
a need to adjust speed, besides use of tapping after drilling.

i

"Ignoramus14749" wrote in message
...
Here's a list of things I want to get from my mill. They all seem
individually doable. I can already use my mill for basic 3D
machining.

So, here's what I want.

1) All panel buttons and jog buttons work properly
2) Spindle Speed control from G code using solenoids that actuate the
vari-drive
(and not VFD), so that I get full power output at all speeds, all the
while operating at 60 Hz
3) Flood and mist coolant working, including from G code
4) Jog mode, VFD at 5 Hz
5) 4th (rotary) axis based onthe Troyke CNC rotary table
6) Rigid tapping, based on synchronization to spindle speed (G33)

Once I do all of the above, I think that it wil be a Mercedes Benz
level mill, loaded with useful features, with everything accomplished
without modifying the hardware of this machine, and without incurring
expensive costs.

Am I missing anything in this picture?

Automatic lube (ways & ball screws)?

Automatic tool changer?

On 2010-08-09, Mike Henry wrote:

"Ignoramus14749" wrote in message
...
Here's a list of things I want to get from my mill. They all seem
individually doable. I can already use my mill for basic 3D
machining.

So, here's what I want.

1) All panel buttons and jog buttons work properly
2) Spindle Speed control from G code using solenoids that actuate the
vari-drive
(and not VFD), so that I get full power output at all speeds, all the
while operating at 60 Hz
3) Flood and mist coolant working, including from G code
4) Jog mode, VFD at 5 Hz
5) 4th (rotary) axis based onthe Troyke CNC rotary table
6) Rigid tapping, based on synchronization to spindle speed (G33)

Once I do all of the above, I think that it wil be a Mercedes Benz
level mill, loaded with useful features, with everything accomplished
without modifying the hardware of this machine, and without incurring
expensive costs.

Am I missing anything in this picture?

Automatic lube (ways & ball screws)?

The mill has that already.

Automatic tool changer?

This is too hard, I would not do it.

i

Ignoramus29207 fired this volley in
:

This is too hard, I would not do it.

The interface is easy. Heck, you could build an "extension ring" for your
rotary table to act as the tool holder.

But you do have to have a power drawbar that can be controlled by EMC. I
don't recall your saying if you had one.

LLoyd

On 2010-08-09, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
Ignoramus29207 fired this volley in
:

This is too hard, I would not do it.

The interface is easy. Heck, you could build an "extension ring" for your
rotary table to act as the tool holder.

But you do have to have a power drawbar that can be controlled by EMC. I
don't recall your saying if you had one.

I do not have a power drawbar. Based on some abysmal past experiences,
trying to implement something like this will lead to a disaster.

i

Ignoramus29207 wrote:

On 2010-08-09, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
Ignoramus29207 fired this volley in
:

This is too hard, I would not do it.

The interface is easy. Heck, you could build an "extension ring" for your
rotary table to act as the tool holder.

But you do have to have a power drawbar that can be controlled by EMC. I
don't recall your saying if you had one.

I do not have a power drawbar. Based on some abysmal past experiences,
trying to implement something like this will lead to a disaster.

i

ATC is nice, but far from critical for a home shop. You already have a
quick change spindle, so as long as you can keep standard tools pre-set
in their holders and numbered for quick change with the tool length
offsets and whatnot properly entered into the control, manual tool
changes should be fast and easy.

One addition that might be worthwhile would be to install a tool length
sensor probe at a far corner of the table to allow fast automated tool
length measurement.

On 2010-08-09, Pete C. wrote:

Ignoramus29207 wrote:

On 2010-08-09, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
Ignoramus29207 fired this volley in
:

This is too hard, I would not do it.

The interface is easy. Heck, you could build an "extension ring" for your
rotary table to act as the tool holder.

But you do have to have a power drawbar that can be controlled by EMC. I
don't recall your saying if you had one.

I do not have a power drawbar. Based on some abysmal past experiences,
trying to implement something like this will lead to a disaster.

i

ATC is nice, but far from critical for a home shop. You already have a
quick change spindle, so as long as you can keep standard tools pre-set
in their holders and numbered for quick change with the tool length
offsets and whatnot properly entered into the control, manual tool
changes should be fast and easy.

One addition that might be worthwhile would be to install a tool length
sensor probe at a far corner of the table to allow fast automated tool
length measurement.

I agree with all of the above.

i

Jon, practically speaking, how fast do you run your spindle when rigid
tapping with small taps?

FWIW, I do all tapping at 200 RPM in back gear. I'm sure you can go faster.

....
My current thinking about the brake is that the pneumatic system is
already made, such that that the brake engages with a delay, but
withdraws instantly. If so, then, the built in delay may be sufficient
to let the VFD stop the spindle.

I recently put a brake resistor on the VFD, and can stop faster than I
used to.

FWIW, I use the VFD and resistor to stop spindle, then bring in brake to hold it there.

Karl

On 2010-08-09, Karl Townsend wrote:

Jon, practically speaking, how fast do you run your spindle when rigid
tapping with small taps?

FWIW, I do all tapping at 200 RPM in back gear. I'm sure you can go faster.

...
My current thinking about the brake is that the pneumatic system is
already made, such that that the brake engages with a delay, but
withdraws instantly. If so, then, the built in delay may be sufficient
to let the VFD stop the spindle.

I recently put a brake resistor on the VFD, and can stop faster than I
used to.

FWIW, I use the VFD and resistor to stop spindle, then bring in brake to hold it there.


Karl, I want to do the same thing. Using whatever you used, how did you specify brake delay?

i

I'm a bit late to your thread... been fighting the new 'puter and helping "the kid" all
weekend.

As to list of new things to add. Consider a servo on the knee and link it to tool height
when doing a manual tool change. Your 2 1/2 axis machine suffers from too small a Z range
and this solves the issue.

Karl

On Mon, 09 Aug 2010 11:55:09 -0500, Ignoramus29207
Karl, I want to do the same thing. Using whatever you used, how did you specify brake delay?

here's my logic: (different language than yours)

[[STOPSPINDLE]]
#34=0 'make sure CCW is off
#35=0 'make sure CW is off
SPINSTOP
LIGHT 4;OFF
SLEEP 1.0
IF #66=1 THEN #44=0:\122=0:LIGHT 10;ON 'if brake is in ON position, turn off
brake release or brake on, flag for brake
\121=0 'flag for spindle off


looks like I just wait 1 second after turning the out off.

On 2010-08-09, Ignoramus29207 wrote:
On 2010-08-09, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
Ignoramus29207 fired this volley in
:

This is too hard, I would not do it.

The interface is easy. Heck, you could build an "extension ring" for your
rotary table to act as the tool holder.

But you do have to have a power drawbar that can be controlled by EMC. I
don't recall your saying if you had one.

I do not have a power drawbar. Based on some abysmal past experiences,
trying to implement something like this will lead to a disaster.

Aside from that -- Iggy's spindle has a quick-change locking
ring for the NTMB/NMTB-30 (whichever) holders. This requires a hook
wrench to lock and release it. So to have a power drawbar (ideally with
the finger cluster to grip a pull ball on a CAT-30 holder or a BT-30 on
a power drawbar).

I agree that adding a tool changer to your machine is not a
practical project for the present. If you stumble across an alternate
head for the machine, with the different spindle and the mounting points
for the turret -- then you might reconsider this project.

Enjoy,
DoN.

--
Remove oil spill source from e-mail
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Ignoramus29207 wrote:

Jon, practically speaking, how fast do you run your spindle when rigid
tapping with small taps?

I have wimpy servo drives, about 5 A peak. I also was still learning
how to set the thing up, and hadn't put a filter in the velocity command
to the VFD. I was having a couple problems. The VFD slammed to a stop
so suddenly the Z axis couldn't always follow it, and I got following
error trips. Also, the electronic motor protection was enabled, and was
tripping the VFD offline. The Bridgeport "pancake" motor is insanely
derated, and is meant to do plug-reverse tapping all day. I just turned
the motor protection off, and added a filter to soften the reversing
action of the VFD. So, after these fixes, I was happily tapping 4-40 at
1000 RPM. I suspect I could go even higher now.
Say you are tapping with 10-32 taps, how fast would you run your
spindle.

Hmm, I think I did some 10-32 tapping at 800 RPM. I made a 12 x 24"
fixture plate with 288 holes. Rigid tapping is WAY cool on a tedious
job like that! I mounted the plate on spacers, indexed the position,
and then did spot, drill through, and tap in one setup, then moved the
plate and did another section.

It should be a manual button, I think, I have not yet figured it
out. I thought about it last night, all the delays etc, it was
painful to think about. This is also a somewhat riskier function to
debug (compared to, say, flood), because of how a brake may fight the
VFD.

You could interlock them, so the button doesn't work when the motor is
on. I have turned on my VFD when the manual brake is locked, nothing
horrible happens, and the belt slips. This may be less desirable with a
varispeed drive. If it takes you too long to react, the VFD will just
fault. I have the VFD fault relay wired into my E-stop chain.
I have to look at the brake fuction more closely.

My current thinking about the brake is that the pneumatic system is
already made, such that that the brake engages with a delay, but
withdraws instantly. If so, then, the built in delay may be sufficient
to let the VFD stop the spindle.
EMC1 had a delay built in for the brake, this has been removed, I think.
But, putting in a delay would be easy in HAL.

Jon