Re: BDI with DRO/Encoder Board

Thanks for the reply Jon.

My continuing saga:
Well I had a few hours before the machinist arrived to debug. I
found that I had not damaged the DRO board after all. It was sitting
in the ISA slot incorrectly. When I corrected the problem the Y axis
came on again. I had some 74LS138's so I swapped out those to see if
Z would come on. It did not. So I swapped the two encoder chips and
X and Y still worked and Z did not. Then I ran the Z motor on the X
axis and it worked. It is looking more and more like a software
problem. I have a copy deskncrt (I guess one could call it emc lite
for DOS) so I will see if the Z axis works with this today.

The machinist and I ran EMC with stepmod.o and tuned it to his liking.
We set the acceleration, velocity and backlash. In adjusting the
backlash I now see why we should of upgraded to ball screws. (We will
be doing this.) The machinist opened the MDI input box, typed in his
own program, saved and ran. The program ran very nicely. First time
we saw this machine "execute" a program.

I will be investigating today the new software. I will see if
changing the PERIOD parameter improves things. Since I am really not
a UNIX guy or a professional programmer it is unclear to me how to
get a tarball of the latest and greatest from sourceforge using CVS.

Dave

--- In CAD_CAM_EDM_DRO@y..., Jon Elson <elson@p...> wrote:
> David Kryskowski wrote:
>
> >
> > I compiled the latest version from linuxcnc.org. dro.h and dro.c
had to be updated from the latest fixes at sourceforge. The install
script is much improved and made life much easier. Running with
smdromod.o is much slower than using the original BDI code.
>
> I think you turned down the P term to 5 to make the double-servo
loop stable. You
> will have to turn it back up for single servo.
>
> > I am not sure what the problem is. It is really unusable when
using the tk interface. The xwin interface is somewhat better and
the mouse somewhat follows your hand movement. I did compare
the .ini files and the timing parameters were the same. Could be
compile optimizations but have not looked into it.
>
> Oh, you are talking about CPU time available for non-RT tasks. If
you are running out of
> CPU resources, you need to reduce the RT load. If using one of the
freqmod derivatives
> (not sure whether smdromod.o is or isn't) then the PERIOD parameter
can be made larger
> to reduce the number of times a second that the pulse generating
code is scheduled.
> Default is 16 uS, which is pretty heavy!
>
> > Our machinist and I will be using the computer control for the
first time tomorrow. We went over the interface together today and
it seems pretty simple.
> >
> > Finally since I can't use smdromod.o for week what is the best
motordriver to use for my appication? Is it stepmod.o or freqmod.o?
I have seen the new ppm code that you wrote at sourceforge (pulse
position modulation?). Should we give that a go?
>
> Are you talking about PPMC? That requires my special hardware, and
for now is servo
> only. I have demonstrated a stepper rate generator version of
this, but it is not quite
> ready, yet. I'm fighting problems integrating the digital I/O with
the rest of it.
> PPMC stands for Parallel Port Motion Control.
>
> Otherwise, stepmod.o gives best steps/second performance on a given
CPU.
> But, if you have resonance or lost steps problems with it, then
freqmod.o gives a
> much smoother step pulse stream, which allows the motors to follow
better.
> It depends to some extent on the motors and stepper drivers used.
>
> Jon