Re: Linux vs. DOS

> -----Original Message-----
> From: "Matt Shaver" <mshaver@...>
>
> 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.
>

I have my request in for one of these boards from Dan. So, if you need
someone to test a closed loop stepper system I will be available.

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

I spent 3 hours messing with this tonight and I still can not get the X axis
to move in the correct direction. The Input Scale settings took care of
getting the EMC movement distances to match the actual table move distances,
but it did not seem to matter whether the OUTPUT_SCALE was set to positive
or negative, the X axis just wants to go in the wrong direction. I imagine I
could swap the wiring to the stepper for the X axis to get the rotation to
reverse, but this sure seems like it should be a software setting.

> 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).
>

I fiddled with these settings and did get the acceleration rate to be more
appropriate, but none of these settings seemed to change the fast move "G0"
rate. I also noticed that regardless of the rate I set for MAX_VELOCITY or
DEFAULT_VELOCITY the feed rate setting that comes up in Xemc is always 60
and that appears to be the speed it tries to go. Might be easy for your
servos, but it sure makes a terrible racket with the steppers!!

> > 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 tried entering the line as Jon suggested with a M6 command in the same
line as the G42 and still don't seem to have the trick worked out. I will
hold off on worrying about this until I get the basic parameters worked out.

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

This error is still with me. I don't remember it ever happening with DanCAD
or DeskNC so I don't think it is a problem with the hardware (Dan M., Any
chance this could be a controller hardware issue??). I did try moving the
wiring to the controller around a little just to see if it might be some
type of cross talk, but I didn't see any difference.

Frustrated but hopeful,

Tim
[Denver, CO]