开云体育

According to my material selection guide, polyester CTE is 4 E-5 /F, cast
iron is 6 E-6 /F. Most unreinforced plastics as quite similar in expansion
to polyester.
The difference in expansion works out to 3.4 E-5 /F, or 6 E-6 /C.

A 1 C change in temperature will cause a 0.001 inch relative movement in 16
inches between polyester and cast iron.

A usual shop environment is not controlled anywhere close to 1 C, your
milage may vary.

Polyester also has a tensile modulus of around 500 kpsi. Thus a piece 0.004
x 0.5 inch (0.002 sq in) will stretch 0.001 inch in 10 inches with a 0.1
pound tension.

The other side of this stretchyness is that if held by its ends under a
little tension in a metal frame, its length will equal that of the metal
frame, as long as it remains under tension at the highest temperature of
use.

Moral of story: keep it under tension.

Elliot Burke
HighTide Instruments

From: "Matt Shaver" <mshaver@...>

I agree, plus the DanCAM pinout seems to have two digital I/O
bits on the
same port with the step and direction signals. Also, I notice
the popular
pinouts don't have home switches either, so this whole area
needs to be
rethought. See:



for a chart of popular pinouts.

Actually, the DanCAD pinout has provisions for limit switches (All axis's +
& - are ganged together to one input) and for home switches on all 3 axis's
along with 3 (if I remember correctly) relays. The newest version of DeskNC
DOS supports 4 axis's with home switches on all and limit switches all
ganged to 1 input along with 3 or 4 (don't remember which) relays. You may
want to go to the page I am putting together on hooking up a controller at
and get the file that that is
connected to the "Download this .dxf file". It will give you the pin
assignment for DanCAD along with a change to make the same setup work for
DeskNC DOS.

The correct axis's now move and I can make all 3 of them

go. Whoopee!!

The only problem is one of the axis's moves in the wrong

direction. Guess
I

need to know how to configure the direction. Another

problem is that the

physical movement is much larger than the amount entered in the

controller.

My X and Y settings are 4000 steps per inch and my Z

setting is 5600 per

inch. Another parameter I need to learn to set.

See:



way down the page for a description of how to set up the .ini file
parameters. I think you need to look at the INPUT_SCALE
parameter to get
the scaling right, and the OUTPUT_SCALE to get the direction
right. For
INPUT_SCALE I think you need it set to 4000 for X and Y, and
5600 for the
Z. To reverse the directions change OUTPUT_SCALE = 1.000 0.001 to
OUTPUT_SCALE = -1.000 0.001 for the backwards axis. I'm not
sure of the
implications for you of that 0,001 in the OUTPUT_SCALE
parameter, I'll have
to ask Fred.

I read through the page and couldn't quite figure out how the numbers
related to a stepper setup as all the descriptions were for servos. I will
make the changes, see what happens and let you know.

The default fast move (G00) speed is WAY too fast for my

poor steppers.
They

just make a terrible groan trying to rotate at that speed.

Again, another

thing I need to learn how to configure.

Reduce the DEFAULT_VELOCITY, DEFAULT_ACCELERATION, MAX_VELOCITY and
MAX_ACCELERATION parameters. Velocity is in inches per second
and I think
acceleration is in/sec/sec. I would think a velocity of 1 and an
acceleration of .1 would be a starting point for you (this is
a guess).

Again, I will make these changes and report back.

When the program hit a line with a G42 cutter comp entry I

got the error

message "convert_cutter_compensation_on error 43 blah,

blah, blah"(OK, I

didn't write it down). This is even with a line in the

program to specify

the tool (T1).

I think I need to see the code, the error, and what's in your
tool table
for this one.

I will try to get it all together and send it to you tonight.

I am mighty confused about how to step through a program as the step
function only seems to work once you press run and then

pause. Any idea
how

I step into a program instead of having to panic and click

pause before 4

lines have processed?

Sorry, that's how it works for now and there are other single
stepping bugs
you haven't experienced yet. This is an area of continuing
development.
Very soon there will be a big change to the motion control
code that speeds
up the block processing rate, and this also affects the
single stepping
problem.

I can live with it for now. I just wanted to make sure it wasn't my lack of
understanding that was causing the problem.

Major problem. If I only move the X or Y axis all is fine.

If I move the
Z

axis I start to get random very ragged movement in the X

axis and any

movements issued for the X axis are interpreted incorrectly

while this

random movement is occurring. If I make some more movements

on the Z axis

the X axis movement problem will randomly go away and then return.

Try getting the .ini parameters right and see if this goes
away. If not,
we'll examine this more carefully.

I keep you posted.

Thanks again,

Tim
[Denver, CO]

I haven't heard much discussion about sources for servos. What are people
using out there?

I remember a Circuit Cellar column in the early days of Byte wherein Steve
Ciarcia described a neat hack for controlling DC Motors via rotary encoders
for a robotics project. He was enthusiastic about their cheapness compared
to steppers of the day ( on a $/in-lb basis). IIRC he built his own encoder
using a gray-coded paper wheel.

Fellow listers, I submit that we don't need expensive servo motors to
control our brand of basement CNC, just your common DC brush motor, perhaps
from the ubiquitous cordless drill, or auto power window winder, or
windshield wiper motor. DC motors are cheap and plentiful, and we can use
them for our machine tool conversions.

What say y'all?

Phil Plumbo

Tim I have bought some of those rs232 breakout boxes and reconfigured the
pins for various customers. It will alow you to keep your current parallel
port cable and save you from fighting the process of making up a new cable.
I think you can buy them at radio shack for $8-9 or at other places for
$4-5.

From: "Tim Goldstein" <timg@...>

From: "Matt Shaver" <mshaver@...>

All I can say is I am glad the kill button wired in with the limit

switches

is working fine!!

This is much less of an issue with steppers than with servos. Usually, when
something goes wrong with steppers they don't move. When something goes
wrong in a servo motor system the faulty axis takes off at max velocity
(for your average knee mill this is maybe 200-300 ipm) in one direction.
This isn't too bad on the X or Y axis unless something is in the way, but
on the Z axis where there are only 5 inches of travel stop to stop it's
pretty hairy. I've experienced enough runaways now that my heart doesn't
stop completely anymore, but I usually keep my hand on the estop switch
until I have built up confidence in a system.

I guess there are a lot of unanswered
questions that will come up like:

1. With no feedback (encoders) what do P, I, D, and a bunch of other
parameters in the .ini file mean?

Guess with these when you know I will then understand what they are. It

just

so happens that I do have encoders on my motors. They are 200 step per
revolution units and right now are not used at all. If there is any way

to

run the steppers with feedback provided from the encoders it would make

for

a pretty sweet setup. It would give the low cost setup of steppers and

the

closed loop positional guarantee of servos.

P, I, and D are various gain factors that interact in mysterious ways
inside the control software to affect the way the servos respond to
commands and external forces. Unless I'm wrong they are only relevant if
there is position feedback. I don't see why your encoders couldn't be used
by the EMC software for exactly the purpose you have described. First, you
will need an inexpensive quadrature interface board for your PC. The Tom
Kulaga/Dan Mauch DRO board snaps immediately to mind. I'm getting a couple
of these when Dan gets them done and I'll forward one to Fred for his
perusal.

2. We'll need to change the incremental jog menu items to match your

step

size.

Not quite sure what you mean here, but I definitely need to change the
setting to take my step size in account as it is way off.

Actually, I mean that you can set the jog increment in xemc to .0001 and
that is probably smaller than one of your steps. the minimum here should be
one step, and the larger values should be multiples of the step size, which
I think they already are (.001, .01, .1, continuous).

3. Since in the servo systems we use a parallel port for spindle and
coolant control along with estop, lube oil level sensing, etc. will we

be

able to add another port to your machine for these functions? What kind

of

mill is it? What controller, if any, were you using before?

Everything is home shop stuff. the controller is one of Dan's 5 amp

choppers

and the mill is a Shoptask 3 in 1. Out of the list of extra functions the
only thing I may ever have a use for is the coolant control and that is

only

if I ever get around to putting a solenoid valve in the air line to my

mist

coolant unit. I would not have a problem putting a 2nd parallel port in

if

it is needed, but with my basic setup I don't see the need.

I agree, plus the DanCAM pinout seems to have two digital I/O bits on the
same port with the step and direction signals. Also, I notice the popular
pinouts don't have home switches either, so this whole area needs to be
rethought. See:



for a chart of popular pinouts.

The correct axis's now move and I can make all 3 of them go. Whoopee!!
The only problem is one of the axis's moves in the wrong direction. Guess

I

need to know how to configure the direction. Another problem is that the
physical movement is much larger than the amount entered in the

controller.

My X and Y settings are 4000 steps per inch and my Z setting is 5600 per
inch. Another parameter I need to learn to set.

See:



way down the page for a description of how to set up the .ini file
parameters. I think you need to look at the INPUT_SCALE parameter to get
the scaling right, and the OUTPUT_SCALE to get the direction right. For
INPUT_SCALE I think you need it set to 4000 for X and Y, and 5600 for the
Z. To reverse the directions change OUTPUT_SCALE = 1.000 0.001 to
OUTPUT_SCALE = -1.000 0.001 for the backwards axis. I'm not sure of the
implications for you of that 0,001 in the OUTPUT_SCALE parameter, I'll have
to ask Fred.

The default fast move (G00) speed is WAY too fast for my poor steppers.

They

just make a terrible groan trying to rotate at that speed. Again, another
thing I need to learn how to configure.

Reduce the DEFAULT_VELOCITY, DEFAULT_ACCELERATION, MAX_VELOCITY and
MAX_ACCELERATION parameters. Velocity is in inches per second and I think
acceleration is in/sec/sec. I would think a velocity of 1 and an
acceleration of .1 would be a starting point for you (this is a guess).

When the program hit a line with a G42 cutter comp entry I got the error
message "convert_cutter_compensation_on error 43 blah, blah, blah"(OK, I
didn't write it down). This is even with a line in the program to specify
the tool (T1).

I think I need to see the code, the error, and what's in your tool table
for this one.

I am mighty confused about how to step through a program as the step
function only seems to work once you press run and then pause. Any idea

how

I step into a program instead of having to panic and click pause before 4
lines have processed?

Sorry, that's how it works for now and there are other single stepping bugs
you haven't experienced yet. This is an area of continuing development.
Very soon there will be a big change to the motion control code that speeds
up the block processing rate, and this also affects the single stepping
problem.

Major problem. If I only move the X or Y axis all is fine. If I move the

Z

axis I start to get random very ragged movement in the X axis and any
movements issued for the X axis are interpreted incorrectly while this
random movement is occurring. If I make some more movements on the Z axis
the X axis movement problem will randomly go away and then return.

Try getting the .ini parameters right and see if this goes away. If not,
we'll examine this more carefully.

I look forward to getting this all worked out and actually making some

chips

with this setup.

"All in good time..", The Wicked Witch of the West in _The Wizard of Oz_

Matt

From: "Tim Goldstein" <timg@...>
Dan, there are a number of things I found out in the installation that I

am

have half kept track of you will need to know.

1 - The kernel update files on the RedHat site were an older version than

I

had on the CD. To get the realtime patch to install all I needed to do

was

load ALL the kernel rpm modules (headers, library, source) that were on

the

5.2 CD.

This is good to know as the kernel_source RPM is like a 10MB download.

In step 2 where you issue the patch command his instructions show a

hyphen

where it should be an underscore. The proper command is: patch -p1 <
../kernel_patch
In step 3 again a hyphen is shown. Do: make modules_install

Sorry, I OCRed this part from a Xerox that my dog chewed on.

In step 4 you may want to put in a way to boot to the old kernel just
incase.

This is also a very good idea and I'm going to update the EMC installation
instructions with your corrections and changes ASAP!

The only other thing I know to watch out for is to use the memory values
from Matt's last list for updating the 64stepper.ini and run.64step378

file

values.

Ditto the above.

Tim Goldstein wrote:

Next I switch to /usr/local/nist/emc and enter the command ./run.mystepper
This seems to start out fine and I see starting emc and then installing
motion module. Then I get the following error message:
segmentation fault
rmmod: steppermod: devise or resource busy
rmmod: rtl_sched is in use
And that is where it leaves me.

If I then enter lsmod I see steppermod and rtl_sched in the list with the
previous 2 entries. steppermod is marked as [uninitialized]. If I try rmmod
manually, I get the error noted above.

Ok, there are a few things that will become clearer after I explain the
behavior. then I'll tell you what is the most likely cause.

kernel modules need to execute some sort of initialization code before
they are accepted by the system as functional. Wow, that Linus and
his team are sure smart! That prevents that seg fault from becoming
a system crash! The kernel module here is having some sort of
problem, and does not complete it's own initialization, thus the
[uninitialized] state. Due to that, nobody can use the module.
A side effect, is that the module can't be removed, either.
the only way to get rid of it is to reboot. You can, however,
rename the .o file for the module, and then insmod that, once
you figure out the problem. but, that is a mess.

What is the most likely cause of the problem is that the command
line parameter specifying the starting location of the shared memory
area does not match any memory area left unused by Linux.
You have to make a special kernel boot entry in LILO to
boot your real-time kernel with a limit on the memory it is to
use. generally, if you have 32MB on your system, you would
tell LILO to boot the kernel with only 31MB, leaving the
top MB unused by Linux. This is explained in one of the
readme files.
the entry in /etc/lilo.conf would look like this :
image=/boot/rtlinuz
label=rtlinux
root=/dev/hda3
append="mem=31m"

then run lilo to update the boot info.

Then, you specify in the command line that installs the module,
the hex address of the start of the shared mem area.
note where the following text appears :
SHMEM_BASE_ADDRESS=0x1F00000


Here is my run.xemc file
#!/bin/csh -f

# Script for running Elson base controller and xemc
# on 32 MB Linux/RT-Linux system for NIST minimill
# with STG board strapped to 0x300

# name of lock file
set lockfile = /tmp/emc.lock

# 'started' is flag that's set only if we create lock file, so
# if we get ^C we won't delete a previous lock file
set started = 0

onintr EXIT

# check for lock file
if (-f $lockfile) then
echo -n "emc is running-- restart it? [y/n] "
set input = $<
if ($input == y || $input == Y) then
echo cleaning up old emc...
else
echo not starting new emc
exit 0
endif
else
echo starting emc...
endif

# create the lock file
touch $lockfile

# and mark that we created it
set started = 1

# kill any xemcs lying around
set pids = `ps ac | awk '$5 == "xemc" {print $1}'`
foreach pid ($pids)
kill -INT $pid >& /dev/null
end

# kill any mmtasks lying around
set pids = `ps ac | awk '$5 == "shvtask" {print $1}'`
foreach pid ($pids)
kill -INT $pid >& /dev/null
end

# kill any mmios lying around
set pids = `ps ac | awk '$5 == "shvio" {print $1}'`
foreach pid ($pids)
kill -INT $pid >& /dev/null
end

# kill motion controller
rmmod shavermod >& /dev/null

# wait a bit for old emc to go away
sleep 3

# install motion module in kernel
echo "installing motion module..."
insmod -f plat/rtlinux_09J/lib/shavermod.o SHMEM_BASE_ADDRESS=0x1F00000
if ($status != 0) goto EXIT
sleep 3
echo "...done"

# run mmio in background
echo "spawning mmio..."
plat/linux_2_0_36/bin/shvio -ini elsonmills.ini &
sleep 6
echo "...done"

# run mmtask in background
echo "spawning mmtask..."
plat/linux_2_0_36/bin/shvtask -ini elsonmills.ini &
sleep 6
echo "...done"

# run xemc in foreground
plat/linux_2_0_36/bin/xemc -ini elsonmills.ini

EXIT:

# stop mmtask
set pids = `ps ac | awk '$5 == "shvtask" {print $1}'`
foreach pid ($pids)
kill -INT $pid
end

# stop mmio
set pids = `ps ac | awk '$5 == "shvio" {print $1}'`
foreach pid ($pids)
kill -INT $pid
end

# now remove kernel module
rmmod shavermod

# remove the lock file, if we create it
if ($started == 1) then
&#92;rm -f $lockfile
endif

exit 0

end of run.xemc file


Note that the SHMEM_BASE_ADDRESS is also set in the .ini
file, so that the programs that run in the Linux environment can
read them from this file.

elsonmills.ini file

; EMC controller parameters for Shaver Bridgeport
; Differences include:
; PARPORT_IO_ADDRESS = 0x378, for builtin parallel port
; SHMEM_BASE_ADDRESS = 0x3F00000, for 63 MB base address
; PROGRAM_PREFIX = programs/, for usual case
; HOME_SWITCH_POLARITY = 1, so they float closed

[EMC]
VERSION = $Revision: 1.5 $
MACHINE = Elson Bridgeport fast traj, 1KHz
NML_FILE = emc.nml
PARPORT_IO_ADDRESS = 0x378

[EMCMOT]
; SHMEM_KEY and SHMEM_BASE_ADDRESS can't be read by emcmot, so if you change
; them here from their compile defaults in emcmotcfg.h, change the scripts
; to pass them as command line arguments, e.g.,
;
; 'insmod emcmotmod.o SHMEM_KEY=101 SHMEM_BASE_ADDRESS=0xF00000
;
; or
;
; 'emcmotsim SHMEM_KEY=101 SHMEM_BASE_ADDRESS=0xF00000'
;
; Note that changing SHMEM_BASE_ADDRESS will also require setting up shared
; memory by editing /etc/lilo.conf and re-running /sbin/lilo
SHMEM_KEY = 100
SHMEM_BASE_ADDRESS = 0x1F00000

; these are not used by emcmot and thus need only be changed here
COMM_TIMEOUT = 1.0
COMM_WAIT = 0.010

[RS274NGC]
VARIABLE_FILE = rs274ngc.var

[DISPLAY]
POSITION_OFFSET = RELATIVE
POSITION_FEEDBACK = ACTUAL

[TASK]
CYCLE_TIME = 0.020
PROGRAM_PREFIX = /usr/elson/nmlwrite/

[TRAJ]
AXES = 3
LINEAR_UNITS = 0.03937007874016
ANGULAR_UNITS = 1.0
CYCLE_TIME = 0.005
DEFAULT_VELOCITY = 3.0
DEFAULT_ACCELERATION = 2.0
MAX_VELOCITY = 3.0
MAX_ACCELERATION = 2.0

[AXIS_0]
TYPE = LINEAR
UNITS = 0.03937007874016
P = 100.000
I = 0.250
D = 0.150
FF0 = 0.000
FF1 = 5.000
FF2 = 0.000
BACKLASH = 0.000
BIAS = 0.000
MAX_ERROR = 50.000
CYCLE_TIME = 0.001
; note-- changed input scale from -10000 to 10000, for motor test stand
INPUT_SCALE = 20000 0
OUTPUT_SCALE = 1.000 0.000
MIN_LIMIT = -36
MAX_LIMIT = 36
MIN_OUTPUT = -10
MAX_OUTPUT = 10
HOMING_VEL = 0.1
FERROR = 0.075
ENABLE_POLARITY = 1
MIN_LIMIT_SWITCH_POLARITY = 1
MAX_LIMIT_SWITCH_POLARITY = 1
HOME_SWITCH_POLARITY = 1
HOMING_POLARITY = 1
FAULT_POLARITY = 0

[AXIS_1]
TYPE = LINEAR
UNITS = 0.03937007874016
P = 100.000
I = 0.250
D = 0.150
FF0 = 0.000
FF1 = 5.000
FF2 = 0.000
BACKLASH = 0.000
BIAS = 0.000
MAX_ERROR = 50.000
CYCLE_TIME = 0.001
INPUT_SCALE = 20000 0
OUTPUT_SCALE = 1.000 0.000
MIN_LIMIT = -36
MAX_LIMIT = 36
MIN_OUTPUT = -10
MAX_OUTPUT = 10
HOMING_VEL = 0.1
FERROR = 0.075
ENABLE_POLARITY = 1
MIN_LIMIT_SWITCH_POLARITY = 1
MAX_LIMIT_SWITCH_POLARITY = 1
HOME_SWITCH_POLARITY = 1
HOMING_POLARITY = 1
FAULT_POLARITY = 0

[AXIS_2]
TYPE = LINEAR
UNITS = 0.03937007874016
P = 100.000
I = 0.050
D = 0.050
FF0 = 0.000
FF1 = 3.750
FF2 = 0.000
BACKLASH = 0.000
BIAS = 0.000
MAX_ERROR = 50.000
CYCLE_TIME = 0.001
INPUT_SCALE = 40000 0
OUTPUT_SCALE = 1.000 0.000
MIN_LIMIT = -8
MAX_LIMIT = 8
MIN_OUTPUT = -10
MAX_OUTPUT = 10
HOMING_VEL = 0.1
FERROR = 0.050
ENABLE_POLARITY = 1
MIN_LIMIT_SWITCH_POLARITY = 1
MAX_LIMIT_SWITCH_POLARITY = 1
HOME_SWITCH_POLARITY = 1
HOMING_POLARITY = 1
FAULT_POLARITY = 0

[EMCIO]
; section for main IO controller parameters

; cycle time, in seconds
CYCLE_TIME = 0.100

; tool controller
TOOL_TABLE = tool.tbl

; wait times in seconds for spindle brake, release

SPINDLE_OFF_WAIT = 1.0
SPINDLE_ON_WAIT = 1.5

; external digital inputs, outputs are always 0 for 0V, 1 for 5/24V

; digital in bits

ESTOP_SENSE_INDEX = 1
LUBE_SENSE_INDEX = 2

; digital in polarity, 0 is inverted, 1 is normal
; controller compares with polarity, equal means on, not equal means off

ESTOP_SENSE_POLARITY = 1
LUBE_SENSE_POLARITY = 1

; digital out bits

SPINDLE_FORWARD_INDEX = 1
SPINDLE_REVERSE_INDEX = 0
MIST_COOLANT_INDEX = 6
FLOOD_COOLANT_INDEX = 7
SPINDLE_DECREASE_INDEX = 8
SPINDLE_INCREASE_INDEX = 9
ESTOP_WRITE_INDEX = 10
SPINDLE_BRAKE_INDEX = 11

; digital out polarity, 0 is inverted, 1 is normal
; controller writes the polarity to turn on, opposite of polarity to turn off

SPINDLE_FORWARD_POLARITY = 0
SPINDLE_REVERSE_POLARITY = 0
MIST_COOLANT_POLARITY = 0
FLOOD_COOLANT_POLARITY = 0
SPINDLE_DECREASE_POLARITY = 1
SPINDLE_INCREASE_POLARITY = 1
ESTOP_WRITE_POLARITY = 1
SPINDLE_BRAKE_POLARITY = 0

end of emc.ini file

I hope some of this info clears up your most recent problem.
(Then, we can work on the next ones! But, actually, you are
REAL close, now, to getting it all working!)

Jon

From: Dan Falck <dfalck@...>

From: "Matt Shaver" <mshaver@...>
Well, there are of course two approaches to this. One of them involves

a

soldering iron... I'm not a programmer by any stretch of the

imagination,

Tim, make an adapter with a male and female DB-25 plug. Sort of a pass
through connector that crosses signals to fit what you need. I have made

a

few to adapt controllers that were using Dancam and then Maxnc. You

could

pull it in and out of the input path as you test all these programs out.

I thought of this too, but just never typed it. I think that at this point
the best thing to do is figure a way to accommodate all the possible
pinouts with parameters in the .ini file. I'll get Fred to read this thread
and see what he thinks is a good way to proceed. Until then your adapter
idea is the best solution.

To be honest, you are the first person
to control a stepper machine with the EMC.

Now you tell us! :-) The list has been quiet this weekend. I figured
everyone was busy setting up their Linux machines like me. I just got
Redhat 5.2 yesterday and have gone through some of the same things Tim

has

been through, but not gotten as far.

When I read this I immediately thought of the movie _The Flight of the
Pheonix_, 1965. In this an airplane is forced to crash land in the desert
and one of the passengers claims to be an aircraft designer and formulates
a plan to build another plane from the wreckage of the first. When they are
nearly done it is discovered that the engineer is a designer of MODEL
airplanes, a fact he neglected to mention. The captain of the plane (Jimmy
Stewart) is furious and confronts the engineer who is a quiet bookish type.
The engineer defends his idea saying something like, "Well, the principles
involved are essentially the same..." It's a good movie, not like today's
stuff.

I read in one of the READMEs that kernels can be compiled on other

machines

and then inserted into a seperate system. If it could be pulled off for
this, (enhanced RT Linux +Redhat 5.2) it would be a real timesaver.(Fred,
Matt, hint hint ;-) )

I'm happy to send you mine, but it's somewhat specific for the hardware you
have. I'm also happy to compile you one to suit your needs (I run Linux on
a 350MHz P2 with 128MB RAM), but I need to know a bit about your system. If
you have an especially slow system this is a good idea, but you'll miss out
on the learning experience of rolling your own.

I have been watching this thread and am saving all the notes. I hope to

be

the second one to run the stepper EMC. Thanks for all the insallation
advice Matt and Tim!

Let me know where your at in the process and I will do what I can to get
you going.

Matt Shaver

just remember, that no matter what software you use, ALWAYS have an
emergency stop button that kills the power supply/s directly, with no
software inbetween. sure, the software can detect it too, and stop
whatever it's doing, but the first priority is to power down those
motors.

Yes, I second that, strongly! I built up a little circuit that connects up to
the fault relays of the servo amps, and the fault input to and servo enable
from the CNC, and also a manual e-stop chain. This thing allows the
CNC, servo amps or the operator to shut down the servos, and also
kills power to the opto-isolator module that controls spindle, coolant,
etc. In addition to commanding the servo amps to disable, it also
interrupts the main DC power supply to the servo amps, and connects
a load dump resistor to absorb any back-EMF generated by moving
motors. I put this circuit in very soon after setting the thing up, and
it has come in handy a few times. An old version of the EMC would
occasionally break the connection between the user interface and the
servo code. The machine didn't go haywire, you just had no further
control of it. That's a bad enough feeling!

Jon

From: "Matt Shaver" <mshaver@...>
Well, there are of course two approaches to this. One of them involves a
soldering iron... I'm not a programmer by any stretch of the imagination,

Tim, make an adapter with a male and female DB-25 plug. Sort of a pass
through connector that crosses signals to fit what you need. I have made a
few to adapt controllers that were using Dancam and then Maxnc. You could
pull it in and out of the input path as you test all these programs out.

.

To be

honest, you are the first person to control a stepper machine with the EMC.

Now you tell us! :-) The list has been quiet this weekend. I figured
everyone was busy setting up their Linux machines like me. I just got
Redhat 5.2 yesterday and have gone through some of the same things Tim has
been through, but not gotten as far.
I read in one of the READMEs that kernels can be compiled on other machines
and then inserted into a seperate system. If it could be pulled off for
this, (enhanced RT Linux +Redhat 5.2) it would be a real timesaver.(Fred,
Matt, hint hint ;-) )
I have been watching this thread and am saving all the notes. I hope to be
the second one to run the stepper EMC. Thanks for all the insallation
advice Matt and Tim!

Thanks,
Dan Falck

I am running a Shoptask machine with some Superior 550 in/oz bi-polar
steppers on each axis. I use one of Dan Mauch's 5 amp controllers and

power

the CNC stuff from a 24 VDC 20 amp surplus power supply. I have been

running

it from DeskNC DOS version. I also have DeskNC Win95 , DanCAD, and

Stepster

all set up on the system just to see what I like. Of the group of

software

products DeskNC DOS seems to be the most stable.

I became interested in a program that would provide G42 offset support as
the Vector (the CAD/CAM product I am using) is designed to output it's
G-code using offsets. So, with all the software I currently have I must

go

in and manually draw offset paths and then remove the G42 and G40 command
from the code. A big pain, but workable. I was considering MaxNC, but

with

all the talk about EMC on this list I though I would give it a try

before

shelling out some more $$$ for this hobby.

I got this message when I sent my reply about the parallel port stuff.
Vector sounds similar to what I'm using as it operates the same way.
Drawing an offset path is a pain especially if you use reground tools!

I would very much prefer if we can find a way to get it reconfigured in

the

software as all the other programs I have installed are configured for

this

particular setup. This particular configuration is what is specified for
DanCAD which to my taste is better documented in how to interface the
controller to the parallel port than any of the other software I have

seen.

I'll call Fred tomorrow and let him know what you want to do. It seems
there are two "standard" pin assignments for stepper control from the
parallel port, the DanCAM one and the one used by SuperTech for their
software. See:



Matt

From: "Matt Shaver" <mshaver@...>
Well, there are of course two approaches to this. One of them involves a
soldering iron... I'm not a programmer by any stretch of the imagination,
and I don't think this is in the .ini file. Give me a little while to dig
through the EMC source directories here and I'll get back to you. I just
cooked some burgers on the grill, and I'm going to eat a few and think
about this. It's probably in some file called parport.h or stepper.c, or
something like that. I can imagine it involves some changes that we can

do

without involving the software folks such as just changing a few numbers.

Well, I am wrong. I searched and searched and the best I can come up with
is /usr/local/nist/emc/plat/rtlinux_09J/src/extsmmot.c which has some stuff
in it that looks like it relates to the parallel port. I also started to
learn about the grep command, but I don't know what to search for. To be
honest, you are the first person to control a stepper machine with the EMC.
Fred Proctor has a little test stand that consists of a stepper motor
driver box from Microkinetics with three little, probably size 15, stepper
motors stuck to the lid of the box with double sided tape. You are the only
one that has stepper motors coupled to a mill. All the other installations
are servo motors. Congratulations. I guess there are a lot of unanswered
questions that will come up like:

1. With no feedback (encoders) what do P, I, D, and a bunch of other
parameters in the .ini file mean?

2. We'll need to change the incremental jog menu items to match your step
size.

3. Since in the servo systems we use a parallel port for spindle and
coolant control along with estop, lube oil level sensing, etc. will we be
able to add another port to your machine for these functions? What kind of
mill is it? What controller, if any, were you using before?

I'll talk to you later, and in the mean time you might want to look around
and find your soldering iron.

Matt

From: "Tim Goldstein" <timg@...>

Oh my gosh!!! XEmc came up and I moved the table in manual mode!!!!

Gee, I didn't know you had hardware. I thought you were just checking out
the GUI. This is great!

The error seemed to be in the entry for the memory. I have 32 MB in the
machine and had it set for 0x2F00000. As soon as I changed it to

0x1F00000

in both run.mystepper and in the 64stepper.ini files I was able to get it

to

start.

Sorry, my fault there I'm afraid.

On to my next problem. I am wired to different outputs than emc defaults

to.

What file do I need to edit to get the correct axis to move? I am wired

as

follows:


Step Direction
X axis D0 D4
Y axis D1 D5
Z axis D2 D6


All limit switches ganged on S6

Well, there are of course two approaches to this. One of them involves a
soldering iron... I'm not a programmer by any stretch of the imagination,
and I don't think this is in the .ini file. Give me a little while to dig
through the EMC source directories here and I'll get back to you. I just
cooked some burgers on the grill, and I'm going to eat a few and think
about this. It's probably in some file called parport.h or stepper.c, or
something like that. I can imagine it involves some changes that we can do
without involving the software folks such as just changing a few numbers.

I am so excited to at least see the table move even if it is not all

axis's

or in the correct direction. I couldn't have gotten this far without your
help.

Amazin', ain't it.

Oh my gosh!!! XEmc came up and I moved the table in manual mode!!!!

The error seemed to be in the entry for the memory. I have 32 MB in the
machine and had it set for 0x2F00000. As soon as I changed it to 0x1F00000
in both run.mystepper and in the 64stepper.ini files I was able to get it to
start.

On to my next problem. I am wired to different outputs than emc defaults to.
What file do I need to edit to get the correct axis to move? I am wired as
follows:


Step Direction
X axis D0 D4
Y axis D1 D5
Z axis D2 D6


All limit switches ganged on S6

I am so excited to at least see the table move even if it is not all axis's
or in the correct direction. I couldn't have gotten this far without your
help.

Thanks,
Tim
[Denver, CO]

Don;

Danplot will read a HPGL plot file, and output the steps to a controller
that takes step and direction inputs from the parallel port. Also you
can make the Z axis trip a relay or transister instead of driving a
motor. Talk to Dan Mauch at Camtronics and here.

'Z' axis trip, eh??....Do you feel this will help me or hinder the
situation somewhat to what can be accomplished from the pen up/down
method? I am assuming this is what you are referring to with the "trip"
method.

What will you bu using the laser for? Is it for cutting wood? If so, how
much power
does that have to be and how much would a laser like that cost.

Yes, I will be cutting 3/8" and thinner balsa wood and some small
engraving with it. The power that I am looking at is around 40
watts(CO2) and I have a price of approx. $4500.00 for a brand new one
from Synrad out on the west coast here in Washington state. I will be
also watching for used specials to pop up every now and then as well. I
have inquired about some specials like this but did not have the proper
setup I was looking for. Either they were missing laser parts or it was
way too overpowered and I would have to setup an elaborate water cooling
system as well. At least with Synrad's 40 watt and lower, they do
guarantee them for air cooling which I do prefer.

I tried manually entering as you suggest and what is happening is I get a
"segmentation fault" error message when I enter the line "insmod -v
/usr/local/nist/emc/plat/rtlinux_09J/lib/steppermod.o
SHMEM_BASE_ADDRESS=0x3F00000 PARPORT_IO_ADDRESS=0x378"

Remember that if your machine has other than 64MB of RAM you'll need to
change the 0x3F00000 to match your system:

0x0F00000 for 16MB systems
0x1F00000 for 32MB systems
0x2F00000 for 48MB systems
0x3F00000 for 64MB systems
0x4F00000 for 80MB systems
0x5F00000 for 96MB systems
0x6F00000 for 112MB systems
0x7F00000 for 128MB systems
etc...

Note: The table of values I provided in a previous post was WRONG with
respect to 16MB and 32MB systems!

If I do a lsmod I see steppermod as used by [uninitialized] and stl_sched

as

used by steppermod just like from the script.

You'll need to rmmod them to try again, and if you can't get them to go
away you'll need to reboot to start over.

I have to do some work around the house to keep the better half happy,

but

if you will be at the number listed in your message in the early evening

I

will try giving you a call.

In between your messages I've been outside mowing, trimming, and shoveling
mulch, so I know what you mean. My wife also likes steamed crabs so I might
run out get her a dozen, although on Memorial Day they're going to gig me
for $20/dozen for smalls (should be $8-$12/dozen here in Baltimore on a
regular day).


Thanks,

Matt
410) 521-3715

Matt,

I tried manually entering as you suggest and what is happening is I get a
"segmentation fault" error message when I enter the line "insmod -v
/usr/local/nist/emc/plat/rtlinux_09J/lib/steppermod.o
SHMEM_BASE_ADDRESS=0x3F00000 PARPORT_IO_ADDRESS=0x378"

If I do a lsmod I see steppermod as used by [uninitialized] and stl_sched as
used by steppermod just like from the script.

I have to do some work around the house to keep the better half happy, but
if you will be at the number listed in your message in the early evening I
will try giving you a call.

Thanks,

Tim
[Denver, CO]