Re: Linux vs. DOS

> 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:

http://www.super-tech.com/root/scxyzsup.htm

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:

http://www.isd.cme.nist.gov/projects/emc/emcsoft.html

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