Re: [CAD_CAM_EDM_DRO] Re: Lost Steps (Me again)

> From: Kevin P. Martin <kpmartin@...>
> >From: Matt Shaver [mailto:mshaver@...]
> >But it works fine with different software. I don't disagree about what

you're

> >saying about the motors, but if different software fixes the problem, then
> >the software must be the problem. Isn't it?
> >
> It is the combination that is the problem. If you change any one thing
> (software, motor driver, or motors), the problem goes away (or changes).
> Although the software is the easiest thing to change, that doesn't mean

that's

> where the blame lies.
> Unless you feel you must lay blame in order to aim a lawsuit at the correct
> party, the fact that you now have a combination that works should be all

you

> need to know. On the other hand, if the "working" software is not

acceptable for

> some other reason, it would still be nice to actually *understand* the

problem

> so you can solve it directly rather than groping around in the dark.

You're right that this problem is due to a combination of deficiencies. The
reason I'm concerned about the software is that I was somewhat involved in
the creation and promulgation of the EMC software (and the freqmod module for
running stepper motors in particular), that's not working in this
application. Since Tim's Shoptask works with the EMC software, and Jerry's
doesn't, we can reason that there is some difference in the motors or drivers
that accounts for this difference. The thing is, Jerry's machine runs with
CNCPRO, and Tim's probably will too (although that would be a good test).
Even if Jerry's motors and drivers are less capable than Tim's, CNCPRO is
capable of delivering a step pulse stream that runs his machine, while the
EMC software can't (given the same PC and other hardware). What I am
searching for is a way to get the EMC software to perform as well as , or
better than, any of the other programs out there and the ability to
successfully run marginal systems is a test of the software's quality.

> From: Tim Goldstein <timg@...>
> Not disagreeing that the software is part of the problem, but I don't think
> it will be the total answer. Sounds to me like the motors are being run in

a

> manner that is marginal (not enough voltage) and the uneven pulse train

from

> EMC is aggravating the condition.

Actually, that's how I read it too. I just can't criticize the guy's motors
if he can get them to work with another program. I'm surprised by the accel
rates you're able to use! Maybe if Jerry increases the motor current, or does
more tweaking in the .ini file, he'll be able to run with the EMC.

> Matt, what is happening with the idea of using an external pulse generator
> for the stepper module. Sure sounds like it would cure this problem and
> reduce the required system resources.

Jon Elson's making really good progress on a parallel port connected machine
control peripheral that will offer plug-in modules for quadrature decoders, D
to A converters, general purpose digital I/O, and eventually a programmable
step pulse generator. He's got the D to A board up and talking to the PC
after some difficulty with the sparsely documented EPP mode of modern
parallel ports. Using this mode allows for high rate data transfer and
deterministic behavior (a problem with USB and Ethernet), without having to
open the case of the PC (laptops!!). There's still a lot to do, but this is a
major accomplishment. The stepper module will probably be the last to be
created. I guess you could say it's in the "conceptual" phase of development
;)

Matt