Re: Linux vs. DOS

> 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:
>
> http://www.super-tech.com/root/scxyzsup.htm
>
> 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
http://www.ktmarketing.com/parallel.html 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:
>
> 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 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]