开云体育

rtr@...
This procedure isn't difficult, but must be understood to successfully
install a rotary encoder where none have been before.

The end of a screw usually has a centerdrilled hole, the screw is usually
hardened , but the core is quite soft to take shock. A good way to do this
is to drill the appropriate pin size ( a hardened drill blank works well)
while the lead or ball screw is assembled in the machine. Don't use a
carbide bit, because if it shatters, you are in deep trouble. Try a slight
interference fit first, It won't come out that way when you use a hand
electric drill. Try for at least a one inch depth. If the screw has
enough metal sticking beyond the bearing, you can go for 1 and a half or
two inches. This means the pin will tend to cock less in the hole.
Obviously, if there isn't going to be much wall thickness left in the
screw, make an adapter pin so you can use a smaller diameter hole and still
have the same sized pin end at the encoder as the encoder shaft.

Then drill and tap for a couple of set screws at 90 degrees to allow you to
indicate it in. Put the indicator near the end of the pin, because that's
where the coupling will fit. The pin doesn't needto stick out more that an
inch when you finish. You can cut it off and file the end when you have it
in place, indicated, and clamped with the set screws. Do thiswork on the
pin gently then indicate it again. Encoders don't like a lot of vibration
so bring it within 3 thousandths or better. I'm always happier if it
comes within one and a half thousandths.

You can connect it with an oldham coupler or similar low inertia couplers.
Surprisingly, if you mount it so the shaft pin and the encoder pin come
within a few thousandths beyond the slop in the system, you can use a piece
of surgical tubing for the coupling. You can add an outer layer of heat
shrink tubing if you think the surgical tubing is too compliant, but I've
never had to. The extra stiffness will transmit more vibration to the
encoder, a bad trade off. There is little friction in good encoder
bearings so the surgical tubing wall thickness is adaquate for a coupling.
Obviously, you can't do this if you need to drive the screw or brake it
through the encoder shaft, a bad idea in any case.

Besides eccentricity in the rotation of the encoder coupling pin, the error
that kills the most encoders is failure to allow enough room between the
ends of these two shafts. All sorts of distortions occur when an axis is
stopped after a rapid movement. Ten thousandths of longitudional slop is
not unusual in a ball screw, more in an acme screw. I take a leather or
wooden mallet or a carefully handled babbit hammer and carefully tap the
screw longetudinaly toward the encoder to get some idea of how much
longitudinal slop must be allowed for. Do this on the other end of the
screw, driving it toward the end with the pin. You aren't worried about
how much it retreats from the encoder. If you can't get to the other end
of the screw, clamp something to an accessible part of the slide and tap it
toward the encoder end from there.

Once you have some feel for this longitudinal travel, use shim stock to set
the dial indicator away from the end of the pin by a your estimated amount
and make sure that the same taps do not show up on the dial indicator. If
they do, increase the pin to encoder shaft clearance.

You need to indicate the encoder mount so its shaft is concentric with the
pin you just installed. Sometimes its easier to leave the pin you
installed full length until you have indicated in the encoder mount. It's
a good idea to drill and ream for taper pins when you have the encoder
mount indicated in. If you have a choice, countersink the encoder mount so
the encoder fits snugly, and use servo clamps if the encoder will accept
them. Clamp the indicator to the pin and indicate the countersunk encoder
locating hole wall.

The last trick works for feeling eccentricity here and other places you may
want to check for it. CAREFULLY rest a screwdriver blade on the pin, then
on the encoder shaft so the screwdriver blade is pulled away from your hand
when the shaft is rotated, and so it won't interfere with your coupling.
If, when you are moving the axis rapidly, you feel a bounce on the shaft,
you did something wrong. Start over.

One fix you don't want to have to do is locktite an oversized pin into the
end of the shaft and then machine it while you traverse the axis. Don't
use a hardened drill blank for this approach. I've installed lots of
encoders and this is a distillation of those experiences.

Ted Robbins

From: Jon Elson <jmelson@...>
A properly designed stepper driver shouldn't be troubled by operating
with no load. Unplugging or plugging in the motor while the driver is
active could cause some arcing that might cause damage, but just running
the driver with no motor connected shouldn't be a problem.

Jon, unfortunately both types of board I have here warn that this is a
certainty
and I believe the Camtronics boards are the same. I have inadvertantly
killed one that way.
It must be in the design, as you say. Where a manufacurer warn specifically
that their design
will be seriously damaged by this - it is good to take the precaution.

Here's what I did, although it is on a servo system, but the problems are
similar. The E-stop signal on my system releases a pair of relays (one
a signal size, the other a power contactor). When these relays are
released, they connect a power resistor to the servo amps power
input, discharging the power supplies. When the relays are engaged,
first the signal relay closes, connecting the same power resistor in
series with the DC supply and the servo amps. Another contact on
this relay connects power through to a time delay circuit. After
a 1 second delay, giving time for the resistor to ramp up the
voltage in the servo amps, the power contactor closes, delivering direct
power to the servo amps. When this relay closes, it also connects
the enable input to the servo amps to +12, turning them on.
This gets rid of all the high DV/DT transients when powering things
up and down, and makes sure that whenever there is a fault, everything
is powered down in a controlled manner.

Perfect power up and enable sequencing. The power bleed resistors are the
absolute
minimum needed for those that do not have a similar set-up and are still in
the process of playing around with their assembly.
Jon do you have a schematic for that set-up - if not I could knock something
up and put it on Tim's site for members who would like to go that route.


Mo

there is a lot of electrical/electronic knowledge on this list
so I thought I would ask here
I have a hardinge hct chucker that is 440v 3 ph
hardinge recommended using a transformer to convert it to
220 instead of rewiring the control box
on 440 it uses no more than 4 amps
where can i get a transformer, hopefully cheap
It mite get converted to cnc but I have to get it running first

thanks
mike

I don't particularly have the time to maintain an FAQ, but I have space
available that I can host it on if others would volunteer to write it and
send me updates.

Tim
[Denver, CO]

Hi, I'm new to the list, thought I'd introduce myself. I presently have
a heavily modified MAXNC and am building a CNC retrofit for my Hardinge
chucker, Omniturn style.
Using Ah-ha software at the moment on the MAX, but I'm going to be
building up a Linux box and giving that a shot.
Modifications to my MAXNC include 198 oz/in PacSci motors, Computmotor
OEM 650 drivers, motor mount plates with preloaded ball bearings to
handle thrust loads, BS&A ActiveCam nuts and 16 pitch screws, a Sherline
spindle assy and DC motor.
Somewhere down the road when I get some free time I'm going to post
drawings of all the mods, making them available at no cost.
If anyone has seen the Flashcut CNC Sherline at the Santa Clara Machine
Tool show a couple years ago, I built it.

Something I just ran across that might be of interest to some folks is a
new low cost ball screw from Thomson. They have a design contest going
and are giving out free samples for as long as they last, you can apply
at
Just got mine today. These sure are no substitute for ground or even
precision rolled screws, but they just might have some potential for the
low end HSM CNC. Screw dia is fixed at .380 with a 16 pitch. Lengths
available are 6", 12, 18, 24, 36, and 48".
Nut has no provisions for mounting and is .75 in dia and .775 long.
There is a single return tube held in place by an injection molded cap.
Backlash specs are between .002 to .007, mine came in at .005. It should
be possible to clamp two nuts in a split block with perhaps a spring
washer to help set a light preload (obviously, before the nuts are
clamped).
Mine felt a bit rough, but was dry. A bit of grease helped a lot.
Mounting these on a Sherline would require some significant
modifications, less so for a MAXNC. They might well be a viable option
for a scratch built machine. I saw this in last months Machine Design.
The screw came out of new mfg methods developed for the automotive
industry and mention was made that they could cost as little as $5 ea.
Obviously a qty price, but it ought to give an idea where these might
sit relative to existing ball screws.

Jon

Any Volunteers?????

Bill
List Manager

From: shackle@... (Will Shackleford)

Also, would you mind making the source code publically available?

Sure, just get:



this archive contains:

Backup.bat - back up before making regrettable errors!
ctb.bat - compiles TextButton with JAVAC
ceg.bat - compiles EmcGui with JAVAC
ccc.bat - compiles Communication with JAVAC
veg.bat - runs Appletviewer
emcgui.htm - Web page that loads the EmcGui applet
EmcGui.java
EmcGui.class
Communication.java
Communication.class
TextButton.java
TextButton.class

Basically EmcGui is the main applet code, TextButton is the custom button
that I made and which is used for all the buttons, and Communication is the
object that connects the applet with the EMC. Obviously, I had no idea how
Communication should really be implemented, so for now it does three things:

1. When the GUI asks for information from the EMC, Communication returns the
contents of variables it maintains. When this class is modified to actually
work with the EMC all these variables will be the ones deep in the bowels of
the EMC itself. Also, I cheated with the ToolList and ProgramList, they are
in EmcGui as preinitialized text. This will need to come through
Communication from the EMC.

2. When the GUI sends a command to Communication it modifies it's own
variables accordingly and write out a pseudo NML type command string to the
console.

3. It creates a display of the Boolean variables it maintains that is visible
in the center of the EmcGui screen when the Debug tab is selected. You can
check and uncheck the boxes and watch the display change.

I think I might modify it to make a few commands and status fields actually
connect to the EMC and repost it hoping someone else would finish the job.

Look it over and see what you think. If we can keep most of the changes
within the Communication class (I know EmcGui will also have to change some),
and if the methods for exchanging data with the EMC are consistent, if you
can get a few commands and a few status fields working the remainder should
be just a typing job (yea, sure :) There are also some features in Xemc that
aren't in this Java version. I'll need to extend EmcGui with keyboard support
and some additional menus (maybe you know of a way to do pull down CUA style
menus? How about a File/Open dialog box?).

I wrote this program almost two years ago and I looked at it today while
getting this material together. I thought, "I wrote that?", I hardly
understand what all that stuff means. It will take a day or two of review to
get back in gear with Java, but if you're interested in getting this going,
I'll be glad to help.

Matt

Raynor,

You have come to the right place for information on building a cnc router. I have built two and I am now in the process of building two more, this time with a fixed bridge design.

If you have any questions, please send me a note. I hope to have a web page up in about a month.

Bob Campbell
Euless, Texas

Robert Neidorff wrote:

From: Robert Neidorff <neidorff@...>

Those Indiana General tape drive motors are VERY NICE DC brush motors.
They are very well made and durable. However, as previously said,
they are low horsepower.

I have one which I got surplus. I ran it from a bench variable supply
to see what it would do. I put as much as +60V on it and got it up to
over 1500 RPM. With a belt speed reduction 5:1 or 10:1, it should have
enough torque to move a Bridgeport table, but surely not direct drive.

I can't say for sure, but a 2:1 (or 3:1 at most) reduction ratio should
be sufficient. It depends on how many amps the motor can take
safely, and how much torque you get at that current. 25 in/Lb per Amp
at 5 amps or so is a good starting point. That gets you up to about
125 in/Lbs.

Jon

Dan Mauch wrote:

From: "Dan Mauch" <dmauch@...>

I used an A/C fan that comes on as soon as the power comes up. That way if
the thermal switch should trip the fan continues to run. The only problem
with this set up is that once it shuts down then when it cools off it starts
running the axis again .

The thermal switches should be tied to an E-stop circuit, so it kills all
axes, and informs the CNC control that there is a problem. Much better
to stop all motion than have the other axes continue blindly on their
path, wrecking the workpiece, tool or even the machine itself!

Jon

From: "Mo" <mo@...>

Any of you guys integrating hi power stepper drive units such as Dans or
others with custom power supplies, should consider 2 areas of disconnection
which will cause problems,
1 Driver board driving the phases without a motor connected - can happen
inadvertantly - I've been there

A properly designed stepper driver shouldn't be troubled by operating
with no load. Unplugging or plugging in the motor while the driver is
active could cause some arcing that might cause damage, but just running
the driver with no motor connected shouldn't be a problem.

2 Reconnecting a driver board with the motor voltage present - the high
value smoothing capacitor(s) on your power supply is charged to the full
supply voltage and carries a serious amount of charge - unless you take
action to get rid of it it will stay charged for a very long time.

Yes, connecting a discharged capacitor to a charged one can make some
big sparks.

Both of these situations seriously endanger your valuable boards.
To protect against the driver driving without a motor connected, a good idea
is to use a plug and socket connection for the motor with a couple of pins
more than you need - so if you need 4 pins for your 4 wire motor get a 6pin
plug and socket. Use the 2 unused pins as a loopback - shorting them
together in the plug which is connected to the motor and the socket which is
mounted on the case can then use this short to enable the board. You could
have your DC supply voltage going into the socket via one pin, looping back
in thro the plug when it is connected and then taken from the second pin of
the socket and sent to your board, no motor connected = no DC voltage to
board....the boards I use have an output inhibit pin which must be held low
0v for the board to drive the motors - a high or no connection will disable
the boaard from driving.
I use the above method to feed a ground wire into the socket that then loops
back via the motor plug and then back onto that pin.

This could still cause a spark when plugging in with the power on.

With the other issue of main motor suopply capacitors remaining charged
after switch off, you should use a bleed resistor connected across the motor
supply voltage - eg across the capacitor (s).
The trick here is to get a value of resistor which is low enough to allow
the capacitor to discharge quickly thro it but without drawing too much
current from the capacitors and getting too hot.

Here's what I did, although it is on a servo system, but the problems are
similar. The E-stop signal on my system releases a pair of relays (one
a signal size, the other a power contactor). When these relays are
released, they connect a power resistor to the servo amps power
input, discharging the power supplies. When the relays are engaged,
first the signal relay closes, connecting the same power resistor in
series with the DC supply and the servo amps. Another contact on
this relay connects power through to a time delay circuit. After
a 1 second delay, giving time for the resistor to ramp up the
voltage in the servo amps, the power contactor closes, delivering direct
power to the servo amps. When this relay closes, it also connects
the enable input to the servo amps to +12, turning them on.
This gets rid of all the high DV/DT transients when powering things
up and down, and makes sure that whenever there is a fault, everything
is powered down in a controlled manner.

This also sees to it that there are no hot resistors smoldering away
anywhere, and that the voltages around the servo amps are cut off
in a fraction of a second when need be.

Jon

TADGUNINC@... wrote:

From: TADGUNINC@...

Bill,
I have been all over "one list" homepage, and can not find any
archives...any help or URLs?

Gee, I don't know why. I looked up , and
got their home page. It has a thing in the middle right hand orange
area that says 'find a community'. I entered CAD and clicked
enter, and got a list of lists with CAD in the name. The 3rd one
was CAD_CAM_EDM_DRO, the list in question. I clicked
on that, and got a page that says : View Archives, and has a list
of articles following that. This is just for 'today' s traffic, but it
has a link to 'Archive Index', that has all the archives back to
May 6, which I guess is when this list was started.

I hope this works OK for you. If not, it may be an AOL
browser problem. I'm using Netscape.

Jon

James Eckman wrote:

Because Windows 95+ freaks out when you deny it interrupts, running any
kind of RT is impossible that I know of. (Somebody may know a trick I
don't but that's my experience) However DOS and 3.1 can be completely
shut off at the users discretion in terms of interrupts with no bad
effects other than frozen mice and such. If you really wanted to port
EMC to such a platform, you would have to rewrite the servo tasks as
interrupt service routines. As for real time NT, I've never used it.
However, also having used Linux/GNU in the past with success using
similar hacks, I'd be tempted to go this route for a controller and
not bother with Microsoft anymore. (Unless there was a real serious
customer requirement)

Well, it is not so simple, because EMC is not a single program, but a
combination of several. There is the real-time motion control
component, there is the digital I/O part for spindle and coolant control,
there is the RS-274D interpreter and trajectory planning, and there
is the user interface. The last 3 are generally not real time, but are
separate time sharing processes. If you were going to try to
implement this under DOS or Win 3.1, you would have to deal with the
real time functions, but also provide real-world time-sharing between
cooperating tasks. The final nail in the coffin of these OSs is that
they offer NO PROTECTION to any program component! That
means any mistake could cause the machine to run away! Very
dangerous. Under Linux, even on the occasions where programs
were shut down in the wrong order, or crashed due to some trouble
in the X environment, the real-time motion control was running
totally normally, and I was able to stop motion and shut the servos
down.

Jon

Hi Bill and all, I have been only lurking for a short while but have been interested for some time now in the building of say a 4'x2' router for alumin (thin) wood and various foams. I am still very much watching this list and you probably have had the details or some of them already on the list as to what is the best approach balancing performance with cost. Obviously your guy,s know their 'onions' with regard to the programming side but I must say it is very"double dutch" to me at this stage. I have data from, Supercam,dancad,isel,THK, Thomson,Actuators and ballscrews etc etc but as yet not clear on the best combinations/options.
Therefore I will continue to lurk I guess and pick up more as time goes on. I suspect many others are like me in that regard. It could be good for us 'newbies' if there was a FAQ page somewhere and many of us I think would lap up a "this is how to it deal" with support from independent list people who can confirm it all works.
I read about suppliers who "can't" be contacted as well as those who are most supportive, so decisions can be a bit of a worry.
cheers
Lurker with intent
Raynor J.

EMC users,

I just put a new release of the EMC code on the FTP site. This contains
a fix to the following error abort action and some new features. Thanks
to Tim Goldstein for pointing these out. Details:

1. The following error abort code only looked at errors in one
direction. This explains why the following errors only kicked in half
the time. I wonder how this went uncorrected so long. Perhaps we were
blaming hardware?

2. Part program verification. Forget about the "rs274ngc" command-line
utility I mentioned. There is now a "Verify" button on the xemc GUI.
Click this after you've opened a part program and it will run through
checking syntax, cutter comp gouging, limit violations, etc. Let me know
how well this works.

3. Stepper motor setup is less painful, hopefully. In your .ini file,
set the steps-per-unit value in the [AXIS_*] INPUT_SCALE line for each
motor, and the maximum feed rate you want in the [TRAJ] MAX_VELOCITY
line. The cycle time for the stepper task is calculated automatically.
Note that you still have to tune the MAX_VELOCITY so that you don't
exceed your motor capabilities or
run the stepper task so fast you starve everything else.

See the emc/doc/RELEASE_NOTES, aka emc-14-Jun-1999.txt on the FTP site,
for slightly more detail.

Field experiences greatly appreciated. Happy Flag Day.

--Fred

Has everyone that ask for an encoder recieved a responce (yes-no) from
me?

I am about to start shipping them and want to make sure I have not said
yes too many time for the number of encoders I have.

John Grant

From: paul@...
Subject: Re: EMC C Code

There is a vast difference between being able to compile code on a
platform and actually being able to execute it. With some work, you
could probably compile the EMC code using the Borland compiler. However,
you would not have all of the operating system real time calls that
the code depends on. To be able to run the program, you would need
to build all of the required functionality that is missing on Windows.
Practically speaking, this is not realistic.

Because Windows 95+ freaks out when you deny it interrupts, running any
kind of RT is impossible that I know of. (Somebody may know a trick I
don't but that's my experience) However DOS and 3.1 can be completely
shut off at the users discretion in terms of interrupts with no bad
effects other than frozen mice and such. If you really wanted to port
EMC to such a platform, you would have to rewrite the servo tasks as
interrupt service routines. As for real time NT, I've never used it.
However, also having used Linux/GNU in the past with success using
similar hacks, I'd be tempted to go this route for a controller and
not bother with Microsoft anymore. (Unless there was a real serious
customer requirement)

Jim Eckman

In a message dated 6/14/99 11:37:25 AM Pacific Daylight Time,
rhj-rbj@... writes:

I suspect many others are like me in that regard. It could be good for us '
newbies' if there was a FAQ page somewhere and many of us I think would lap
up a "this is how to it deal" with support from independent list people who
can confirm it all works.

I do not have anyplace to put such a list. If anyone has space, and would
like to run that section of the list, please contact me and we will see what
we can do.
bill
List Manager

I was 3rd
on the list for 2 encoders
mike

John Grant wrote:

BA Thread Data

The above is a good site for information on BA threads, for those that use
them in model making.
bill
Alb.
NM