Re: PIC-Servo

Andrew,
I also have used the pic-servo units, and also have severely modified
(hacked) the code... Here are some suggestions:

> I am currently using the pic-servo product on a 6x9x8 inch

travel, cnc

> mill. I am using a severly modified version of the cnc mill

software that

> kerr had on his web site, to run the machine.

Since you have been able to "severely modify" (add the 4th axis) the
code, I take it you are a programmer and will understand what I did
to overcome some of the drawbacks to the pic-servo....

> now. I have a 2.5hp treadmill motor running the spindle at speeds

from

> 1-7000 rpm. I dont know how they come to a rating of 2.5hp beacuse

this

> thing is a whimpy 2.5.

Just a sideline note here, remember the formula for horse power
includes the rpm in the equation, it might very well develope 2.5 hp
at 7000 rpm...

>
> I like the pic-servo products, but they have some short comings

that I

> have not, as yet, found a way around via software. One is the delay

between

> moves. If you are not in constant contour mode, each move has about

a .25

> second pause before the next move is excecuted.

Yes, I too found this to be undesireable....

>Second, when you are in
> constant contour mode, the delay is gone, but you are left in an

exact stop

> mode. Being in exact stop mode is not a bad thing unles you program

a move

> that requires more than a 90 degree change of direction. The

machine is

> making all moves without deccelerating, so it feels like a thud. On

a small

> machine you dont notice it much, but I think a bridgeport x-axis

would be

> much more noticable.

Yup, know just what you're talking about- THUD! It bothered me too.
This is what I did as the software fix...
As I said before, if you could add an axis, this should be no problem
for you...
You're going to have to change the code in the pathlib.dll, and since
the source is included, take a look at the path.cpp and the path.h
files...
What worked for me is to change the way the code works when it sees a
segment that is greater than the "max angle" in constant contour
mode. Normally, if the next segment has an angle greater than
the "max angle", it drops out of constant contour mode, this adds
the .25 second undesireable delay. What I have done is to change the
speed of the path to compensate for the size of the upcoming angle...
let me explain... I leave max angle set to 180 degrees, anything
greater than that will drop out of constant contour mode, which never
happens because you cannot change a direction greater than that, in
essence it is disabled. Then what I did is, while the processor is
adding segments to the list (see AddLineSeg and AddArcSeg) I also add
the angle between the previuos segment and the present one. Then
when it comes time to Initialize the path and add the path points(see
AddPathPoints), I adjust the speed of the path in the corners
proportional to the upcoming angle. I used the cosine of the angle,
if the angle was 0 degrees then the present speed was multiplied
by "1" or the cosine of 90, and if the angle was 90 degrees then the
speed was the cosine of 90 which is 0 times the present speed...
Obviously it would slow to a stop at 90 degrees, and that was too
slow for me, so any angle greater than 65 degrees would process at
the same slow speed... which made 180 reversals quite smooth,
decelling and acceling into and out of it. (actually I used the cube
of the cosine, because it slowed too much at a 30 degree turn, but
you'll understand that as soon as you do some testing)
How was it done?
What you need to do is to add another float to the segment structure
in the path.h file... I called this "float angle".. and seglist.angle
was where I put the angle of the previous segment verses the present
one. In the path.cpp file, you'll notice that at the bottom of the
functions "AddLineSeg" and "AddArcSeg" there is code to test for
angle between the segments... if it is greater than the max angle,
then a pathbreak is issued.... you want to change this here.
These functions get the present line segment and the previous segment
and do a "dot product" on them (remember vectors? a dot product
returns the angle between two vectors) Instead of deciding to abort
the continuous contour(returning a -1), add the angle that was
returned to the present seglist( "seglist[seglistsize].angle=dot
(pn,qn)" ). Now, with this angle information in the segment list, you
now go to the the function "GetNextPathPoint".. here you will notice
that the second thing he checks is if the path is close enough to the
end to start the decel process, if it is then he starts subtracting
the acc from the vel... It is here that you should also make the
change to the speed based upon the upcoming angle... So if you are
close enough to the end of the segment that you would normally start
to decel, then it is also time to start to slow down for the upcoming
curve. Here is where I decel to a "new" temporary speed based upon
the normal speed times the cosine of the angle. Once you have
finished this segment, then accel back up to the normal speed. This
has worked VERY well for me...
There is more to the code than what I wrote here, but you should be
able to get the basic idea and run with it....
Couple issues to consider, now that there are no breaks in the path,
the paths can get VERY large... You may want to consider increasing
the size of the seglist, i belive his default was 1000, I moved this
to the heap and increased it to 1 meg.... I've run some constant
contours that take several hours and that annoying .25 sec pause is
gone.
It REALLY speeds up the cycle time.

>
> I like to tackle the chalenges, so this is the system for me. If

you are

This was a challenge for me too.. but well worth it once it was
done. I also added a 4th axis, but mine was for a rotary table and it
will now simultaneously interpolate all 4 axes, and I also added the
helical interpolation (moving either Z, Theta, or both while
circularly interpolating) that was missing. I love it now!
I got four of his cards for $180 each and pittman dc servos for $30
each... pretty cheap for a 4 axis servo CNC, it never misses steps
and like
you said, it's fast - 400 ipm.

Hope this gives you some ideas...

Mike